refactor: stop using backend-tasks in packages and plugins

Signed-off-by: Camila Belo <[email protected]>

.changeset/gentle-radios-cheat.md

@@ -0,0 +1,30 @@
+---
+'@backstage/frontend-app-api': minor
+'@backstage/backend-app-api': minor
+'@backstage/backend-dynamic-feature-service': minor
+'@backstage/plugin-catalog-backend-module-aws': minor
+'@backstage/plugin-catalog-backend-module-azure': minor
+'@backstage/plugin-catalog-backend-module-backstage-openapi': minor
+'@backstage/plugin-catalog-backend-module-bitbucket-cloud': minor
+'@backstage/plugin-catalog-backend-module-bitbucket-server': minor
+'@backstage/plugin-catalog-backend-module-gcp': minor
+'@backstage/plugin-catalog-backend-module-gerrit': minor
+'@backstage/plugin-catalog-backend-module-github-org': minor
+'@backstage/plugin-catalog-backend-module-github': minor
+'@backstage/plugin-catalog-backend-module-gitlab-org': minor
+'@backstage/plugin-catalog-backend-module-gitlab': minor
+'@backstage/plugin-catalog-backend-module-incremental-ingestion': minor
+'@backstage/plugin-catalog-backend-module-ldap': minor
+'@backstage/plugin-catalog-backend-module-msgraph': minor
+'@backstage/plugin-catalog-backend-module-puppetdb': minor
+'@backstage/plugin-catalog-backend': minor
+'@backstage/plugin-events-backend-module-aws-sqs': minor
+'@backstage/plugin-scaffolder-backend': minor
+'@backstage/plugin-search-backend-module-catalog': minor
+'@backstage/plugin-search-backend-module-explore': minor
+'@backstage/plugin-search-backend-module-stack-overflow-collator': minor
+'@backstage/plugin-search-backend-module-techdocs': minor
+'@backstage/plugin-search-backend-node': minor
+---
+
+Stop using `@backstage/backend-tasks` as it will be deleted in near future.

.changeset/soft-files-greet.md

@@ -0,0 +1,16 @@
+---
+'@backstage/backend-tasks': minor
+---
+
+This package is deprecated and will be removed in a near future, follow the instructions below to stop using it:
+
+- `TaskScheduler`: Please migrate to the new backend system, and depend on `coreServices.scheduler` from `@backstage/backend-plugin-api` instead, or use `DefaultSchedulerService` from `@backstage/backend-defaults;
+- `TaskRunner`: Please import `SchedulerServiceTaskRunner` from `@backstage/backend-plugin-api` instead;
+- `TaskFunction`: Please import `SchedulerServiceTaskFunction` from `@backstage/backend-plugin-api` instead;
+- `TaskDescriptor`: Please import `SchedulerServiceTaskDescriptor` from `@backstage/backend-plugin-api` instead;
+- `TaskInvocationDefinition`: Please import `SchedulerServiceTaskInvocationDefinition` from `@backstage/backend-plugin-api` instead;
+- `TaskScheduleDefinition`: Please import `SchedulerServiceTaskFunction` from `@backstage/backend-plugin-api` instead;
+- `TaskScheduleDefinitionConfig`: Please import `SchedulerServiceTaskScheduleDefinitionConfig` from `@backstage/backend-plugin-api` instead;
+- `PluginTaskScheduler`: Please use `SchedulerService` from `@backstage/backend-plugin-api` instead (most likely via `coreServices.scheduler`);
+- `readTaskScheduleDefinitionFromConfig`: Please import `readSchedulerServiceTaskScheduleDefinitionFromConfig` from `@backstage/backend-plugin-api` instead;
+- `HumanDuration`: Import `TypesHumanDuration` from `@backstage/types` instead.

docs/backend-system/architecture/05-extension-points.md

@@ -78,7 +78,7 @@ Another pattern that can be used is a type of singleton pattern where the extens
 
 ```ts
 interface ScaffolderTaskRunnerExtensionPoint {
-  setTaskRunner(taskRunner: TaskRunner): void;
+  setTaskRunner(taskRunner: SchedulerServiceTaskRunner): void;
 }
 ```
 

docs/features/search/collators.md

@@ -41,7 +41,7 @@ The default schedule for the Catalog Collator is to run every 10 minutes, you ca
 search:
   collators:
     catalog:
-      schedule: # same options as in TaskScheduleDefinition
+      schedule: # same options as in SchedulerServiceTaskScheduleDefinition
         # supports cron, ISO duration, "human duration" as used in code
         initialDelay: { seconds: 90 }
         # supports cron, ISO duration, "human duration" as used in code
@@ -85,7 +85,7 @@ The default schedule for the TechDocs Collator is to run every 10 minutes, you c
 search:
   collators:
     techdocs:
-      schedule: # same options as in TaskScheduleDefinition
+      schedule: # same options as in SchedulerServiceTaskScheduleDefinition
         # supports cron, ISO duration, "human duration" as used in code
         initialDelay: { seconds: 90 }
         # supports cron, ISO duration, "human duration" as used in code

docs/features/search/concepts.md

@@ -86,7 +86,7 @@ Search chooses to completely rebuild indices on a schedule. Different collators
 can be configured to refresh at different intervals, depending on how often the
 source information is updated. When search indexing is distributed among multiple
 backend nodes, coordination to prevent clashes is typically handled by a
-distributed `TaskRunner`.
+distributed `SchedulerServiceTaskRunner`.
 
 ### The Search Page
 

docs/features/search/getting-started.md

@@ -283,7 +283,7 @@ Backstage Search builds and maintains its index
 [on a schedule](./concepts.md#the-scheduler). You can change how often the
 indexes are rebuilt for a given type of document. You may want to do this if
 your documents are updated more or less frequently. You can do so by configuring
-a scheduled `TaskRunner` to pass into the `schedule` value, like this:
+a scheduled `SchedulerServiceTaskRunner` to pass into the `schedule` value, like this:
 
 ```typescript {3}
 const every10MinutesSchedule = env.scheduler.createScheduledTaskRunner({
@@ -302,16 +302,19 @@ indexBuilder.addCollator({
 ```
 
 Note: if you are using the in-memory Lunr search engine, you probably want to
-implement a non-distributed `TaskRunner` like the following to ensure consistency
+implement a non-distributed `SchedulerServiceTaskRunner` like the following to ensure consistency
 if you're running multiple search backend nodes (alternatively, you can configure
 the search plugin to use a non-distributed database such as
 [SQLite](../../tutorials/configuring-plugin-databases.md#postgresql-and-sqlite-3)):
 
 ```typescript
-import { TaskInvocationDefinition, TaskRunner } from '@backstage/backend-tasks';
+import {
+  SchedulerServiceTaskRunner,
+  SchedulerServiceTaskInvocationDefinition,
+} from '@backstage/backend-plugin-api';
 
-const schedule: TaskRunner = {
-  run: async (task: TaskInvocationDefinition) => {
+const schedule: SchedulerServiceTaskRunner = {
+  run: async (task: SchedulerServiceTaskInvocationDefinition) => {
     const startRefresh = async () => {
       while (!task.signal?.aborted) {
         try {

docs/integrations/aws-s3/discovery--old.md

@@ -36,7 +36,7 @@ catalog:
         bucketName: sample-bucket
         prefix: prefix/ # optional
         region: us-east-2 # optional, uses the default region otherwise
-        schedule: # same options as in TaskScheduleDefinition
+        schedule: # same options as in SchedulerServiceTaskScheduleDefinition
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code
@@ -56,7 +56,7 @@ catalog:
       bucketName: sample-bucket
       prefix: prefix/ # optional
       region: us-east-2 # optional, uses the default region otherwise
-      schedule: # same options as in TaskScheduleDefinition
+      schedule: # same options as in SchedulerServiceTaskScheduleDefinition
         # supports cron, ISO duration, "human duration" as used in code
         frequency: { minutes: 30 }
         # supports ISO duration, "human duration" as used in code

docs/integrations/aws-s3/discovery.md

@@ -36,7 +36,7 @@ catalog:
         bucketName: sample-bucket
         prefix: prefix/ # optional
         region: us-east-2 # optional, uses the default region otherwise
-        schedule: # same options as in TaskScheduleDefinition
+        schedule: # same options as in SchedulerServiceTaskScheduleDefinition
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code
@@ -56,7 +56,7 @@ catalog:
       bucketName: sample-bucket
       prefix: prefix/ # optional
       region: us-east-2 # optional, uses the default region otherwise
-      schedule: # same options as in TaskScheduleDefinition
+      schedule: # same options as in SchedulerServiceTaskScheduleDefinition
         # supports cron, ISO duration, "human duration" as used in code
         frequency: { minutes: 30 }
         # supports ISO duration, "human duration" as used in code

docs/integrations/azure/discovery--old.md

@@ -45,7 +45,7 @@ catalog:
         project: myproject
         repository: service-* # this will match all repos starting with service-*
         path: /catalog-info.yaml
-        schedule: # optional; same options as in TaskScheduleDefinition
+        schedule: # optional; same options as in SchedulerServiceTaskScheduleDefinition
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code

docs/integrations/azure/discovery.md

@@ -45,7 +45,7 @@ catalog:
         project: myproject
         repository: service-* # this will match all repos starting with service-*
         path: /catalog-info.yaml
-        schedule: # optional; same options as in TaskScheduleDefinition
+        schedule: # optional; same options as in SchedulerServiceTaskScheduleDefinition
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code

docs/integrations/bitbucketCloud/discovery.md

@@ -146,7 +146,7 @@ catalog:
         filters: # optional
           projectKey: '^apis-.*$' # optional; RegExp
           repoSlug: '^service-.*$' # optional; RegExp
-        schedule: # same options as in TaskScheduleDefinition
+        schedule: # same options as in SchedulerServiceTaskScheduleDefinition
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code

docs/integrations/bitbucketServer/discovery.md

@@ -63,7 +63,7 @@ catalog:
           projectKey: '^apis-.*$' # optional; RegExp
           repoSlug: '^service-.*$' # optional; RegExp
           skipArchivedRepos: true # optional; boolean
-        schedule: # same options as in TaskScheduleDefinition
+        schedule: # same options as in SchedulerServiceTaskScheduleDefinition
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code

docs/integrations/github/discovery--old.md

@@ -133,7 +133,7 @@ catalog:
         filters:
           branch: 'main' # string
           repository: '.*' # Regex
-        schedule: # same options as in TaskScheduleDefinition
+        schedule: # same options as in SchedulerServiceTaskScheduleDefinition
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code
@@ -249,7 +249,7 @@ schedule:
   timeout: { minutes: 3 }
 ```
 
-More information about scheduling can be found on the [TaskScheduleDefinition](https://backstage.io/docs/reference/backend-tasks.taskscheduledefinition) page.
+More information about scheduling can be found on the [SchedulerServiceTaskScheduleDefinition](https://backstage.io/docs/reference/backend-plugin-api.schedulerservicetaskscheduledefinition) page.
 
 Alternatively, or additionally, you can configure [github-apps](github-apps.md) authentication
 which carries a much higher rate limit at GitHub.

docs/integrations/github/discovery.md

@@ -83,7 +83,7 @@ catalog:
         filters:
           branch: 'main' # string
           repository: '.*' # Regex
-        schedule: # same options as in TaskScheduleDefinition
+        schedule: # same options as in SchedulerServiceTaskScheduleDefinition
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code
@@ -203,7 +203,7 @@ schedule:
   timeout: { minutes: 3 }
 ```
 
-More information about scheduling can be found on the [TaskScheduleDefinition](https://backstage.io/docs/reference/backend-tasks.taskscheduledefinition) page.
+More information about scheduling can be found on the [SchedulerServiceTaskScheduleDefinition](https://backstage.io/docs/reference/backend-plugin-api.schedulerservicetaskscheduledefinition) page.
 
 Alternatively, or additionally, you can configure [github-apps](github-apps.md) authentication
 which carries a much higher rate limit at GitHub.

docs/integrations/github/org.md

@@ -94,7 +94,7 @@ Directly under the `githubOrg` is a list of configurations, each entry is a stru
 - `id`: A stable id for this provider. Entities from this provider will be associated with this ID, so you should take care not to change it over time since that may lead to orphaned entities and/or conflicts.
 - `githubUrl`: The target that this provider should consume
 - `orgs` (optional): The list of the GitHub orgs to consume. If you only list a single org the generated group entities will use the `default` namespace, otherwise they will use the org name as the namespace. By default the provider will consume all accessible orgs on the given GitHub instance (support for GitHub App integration only).
-- `schedule`: The refresh schedule to use, matches the structure of [`TaskScheduleDefinitionConfig`](https://backstage.io/docs/reference/backend-tasks.taskscheduledefinitionconfig/)
+- `schedule`: The refresh schedule to use, matches the structure of [`SchedulerServiceTaskScheduleDefinitionConfig`](https://backstage.io/docs/reference/backend-plugin-api.schedulerservicetaskscheduledefinitionconfig/)
 
 ### Events Support
 

docs/integrations/gitlab/discovery.md

@@ -154,7 +154,7 @@ catalog:
         entityFilename: catalog-info.yaml # Optional. Defaults to `catalog-info.yaml`
         projectPattern: '[\s\S]*' # Optional. Filters found projects based on provided patter. Defaults to `[\s\S]*`, which means to not filter anything
         excludeRepos: [] # Optional. A list of project paths that should be excluded from discovery, e.g. group/subgroup/repo. Should not start or end with a slash.
-        schedule: # Same options as in TaskScheduleDefinition. Optional for the Legacy Backend System
+        schedule: # Same options as in SchedulerServiceTaskScheduleDefinition. Optional for the Legacy Backend System
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code

docs/integrations/gitlab/org.md

@@ -173,7 +173,7 @@ catalog:
         group: org/teams # Required for gitlab.com when `orgEnabled: true`. Optional for self managed. Must not end with slash. Accepts only groups under the provided path (which will be stripped)
         allowInherited: true # Allow groups to be ingested even if there are no direct members.
         groupPattern: '[\s\S]*' # Optional. Filters found groups based on provided pattern. Defaults to `[\s\S]*`, which means to not filter anything
-        schedule: # Same options as in TaskScheduleDefinition. Optional for the Legacy Backend System.
+        schedule: # Same options as in SchedulerServiceTaskScheduleDefinition. Optional for the Legacy Backend System.
           # supports cron, ISO duration, "human duration" as used in code
           frequency: { minutes: 30 }
           # supports ISO duration, "human duration" as used in code

docs/overview/threat-model.md

@@ -41,7 +41,7 @@ The built-in protection against unauthorized access does not by default include
 
 ## Common Backend Configuration
 
-There are many common facilities that are configured centrally and available to all Backstage backend plugins. For example there is a `DatabaseManager` that provides access to a SQL database, `TaskScheduler` for scheduling long-running tasks, `Logger` as a general logging facility, and `UrlReader` for reading content from external sources. These are all configured either directly in code, or within the `backend` block of the static configuration. The appropriate care needs to be taken to ensure that any secrets remain confidential and no malicious configuration is injected.
+There are many common facilities that are configured centrally and available to all Backstage backend plugins. For example there is a `DatabaseManager` that provides access to a SQL database, `SchedulerService` for scheduling long-running tasks, `Logger` as a general logging facility, and `UrlReader` for reading content from external sources. These are all configured either directly in code, or within the `backend` block of the static configuration. The appropriate care needs to be taken to ensure that any secrets remain confidential and no malicious configuration is injected.
 
 In a typical Backstage setup, there is no boundary between plugins that run on the same host. Likewise, there is no boundary between plugins that share the same database access. Any plugin that is running on a host that has access to the logical database of any other plugin should be considered to have full access to that other plugin. For example, even if you deploy the `auth` and `catalog` plugins on separate hosts with separate configuration and credentials, the `catalog` plugin is still considered to have full access to the `auth` plugin as long as the `catalog` plugin has access to the `auth` plugin's logical database. The only way to create a boundary between the two plugins is to deploy them in such a way that they do not have access to each others’ database. This applies to the database facility as well as any other shared resources, such as the cache.
 

packages/backend-app-api/package.json

@@ -52,7 +52,6 @@
   "dependencies": {
     "@backstage/backend-common": "workspace:^",
     "@backstage/backend-plugin-api": "workspace:^",
-    "@backstage/backend-tasks": "workspace:^",
     "@backstage/cli-common": "workspace:^",
     "@backstage/cli-node": "workspace:^",
     "@backstage/config": "workspace:^",

packages/backend-dynamic-feature-service/api-report.md

@@ -25,12 +25,12 @@ import { PermissionPolicy } from '@backstage/plugin-permission-node';
 import { PluginCacheManager } from '@backstage/backend-common';
 import { PluginDatabaseManager } from '@backstage/backend-common';
 import { PluginEndpointDiscovery } from '@backstage/backend-common';
-import { PluginTaskScheduler } from '@backstage/backend-tasks';
 import { RootLoggerService } from '@backstage/backend-plugin-api';
 import { Router } from 'express';
+import { SchedulerService } from '@backstage/backend-plugin-api';
+import { SchedulerServiceTaskRunner } from '@backstage/backend-plugin-api';
 import { ServiceFactoryCompat } from '@backstage/backend-plugin-api';
 import { ServiceRef } from '@backstage/backend-plugin-api';
-import { TaskRunner } from '@backstage/backend-tasks';
 import { TemplateAction } from '@backstage/plugin-scaffolder-node';
 import { TokenManager } from '@backstage/backend-common';
 import { UrlReaderService } from '@backstage/backend-plugin-api';
@@ -210,7 +210,7 @@ export interface LegacyBackendPluginInstaller {
   // (undocumented)
   search?(
     indexBuilder: IndexBuilder,
-    schedule: TaskRunner,
+    schedule: SchedulerServiceTaskRunner,
     env: LegacyPluginEnvironment,
   ): void;
 }
@@ -225,7 +225,7 @@ export type LegacyPluginEnvironment = {
   discovery: PluginEndpointDiscovery;
   tokenManager: TokenManager;
   permissions: PermissionEvaluator;
-  scheduler: PluginTaskScheduler;
+  scheduler: SchedulerService;
   identity: IdentityApi;
   eventBroker: EventBroker;
   events: EventsService;

packages/backend-dynamic-feature-service/package.json

@@ -49,7 +49,6 @@
     "@backstage/backend-common": "workspace:^",
     "@backstage/backend-defaults": "workspace:^",
     "@backstage/backend-plugin-api": "workspace:^",
-    "@backstage/backend-tasks": "workspace:^",
     "@backstage/cli-common": "workspace:^",
     "@backstage/cli-node": "workspace:^",
     "@backstage/config": "workspace:^",