Merge branch 'backstage:master' into patch-2

This commit is contained in:
Valentin Grégoire
2025-06-06 09:06:54 +02:00
committed by GitHub
765 changed files with 19614 additions and 7881 deletions
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/canon': minor
---
We are updating the default size of the Button component in Canon to be small instead of medium.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-confluence-to-markdown': patch
---
Migrate actions to new format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/core-components': patch
---
table actions header support i18n
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/catalog-client': patch
---
Fixed `CatalogClient` error responses for `refreshEntity` and `addLocation`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/create-app': patch
---
Bumped create-app version.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-gitlab': patch
---
Migrate to new action format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-azure': patch
---
Migrating `azure` actions to using the new `zod` schema format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-bitbucket-cloud': patch
---
Migrate `bitbucket-cloud` to new actions format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-github': patch
---
Migrate to using new actions
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/canon': minor
---
We set the default size for IconButton in Canon to be small instead of medium.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder': patch
---
render details for composite property schemas
+9
View File
@@ -0,0 +1,9 @@
---
'@backstage/plugin-scaffolder-node-test-utils': minor
---
**BREAKING CHANGES**
Because of the removal of the `logStream` property to the `ActionsContext` this has been removed from the `createMockActionContext` method.
You can remove this as it's no longer supported in the scaffolder actions.
+21
View File
@@ -0,0 +1,21 @@
---
'@backstage/plugin-catalog-unprocessed-entities': patch
'@backstage/plugin-app-visualizer': patch
'@backstage/plugin-catalog-import': patch
'@backstage/plugin-catalog-graph': patch
'@backstage/plugin-notifications': patch
'@backstage/plugin-user-settings': patch
'@backstage/plugin-kubernetes': patch
'@backstage/plugin-scaffolder': patch
'@backstage/plugin-api-docs': patch
'@backstage/plugin-devtools': patch
'@backstage/plugin-techdocs': patch
'@backstage/plugin-catalog': patch
'@backstage/plugin-signals': patch
'@backstage/plugin-search': patch
'@backstage/plugin-home': patch
'@backstage/plugin-app': patch
'@backstage/plugin-org': patch
---
Added the `info.packageJson` option to the plugin instance for the new frontend system.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/repo-tools': patch
---
Fixed a bug where linting would fail with the generated clients when defining top-level `enum` schema values.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-node': patch
---
Use `LoggerService` instead of `Logger`. This is a non-breaking change, as the `LoggerService` is a subset of the `Logger` interface.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-bitbucket-server': patch
---
Migrate the actions to the new format
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
Added user feedback when opening config docs in browser. The command now clearly indicates what it's doing and provides fallback instructions if the browser fails to open.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
The `BACKSTAGE_CLI_EXPERIMENTAL_BUILD_CACHE` flag has been removed. Existing users are encouraged to switch to `EXPERIMENTAL_RSPACK` instead.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend': patch
---
Migrating to latest action format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-yeoman': patch
---
Migrate to new actions format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/repo-tools': patch
---
Add missing highlight language for the `package-docs` command.
+7
View File
@@ -0,0 +1,7 @@
---
'@backstage/plugin-scaffolder-backend-module-bitbucket-server': patch
'@backstage/plugin-scaffolder-backend-module-bitbucket-cloud': patch
'@backstage/plugin-scaffolder-node': patch
---
Update pull request creation filter to include .gitignore files in the created pull request
+6
View File
@@ -0,0 +1,6 @@
---
'@backstage/plugin-techdocs-module-addons-contrib': patch
'@backstage/plugin-techdocs': patch
---
Improved Keyboard accessibility in techdocs.
+6
View File
@@ -0,0 +1,6 @@
---
'@backstage/plugin-notifications-backend-module-email': patch
'@backstage/plugin-notifications-backend': patch
---
Internal changes to switch to the non-alpha `catalogServiceRef`
+9
View File
@@ -0,0 +1,9 @@
---
'@backstage/plugin-catalog': minor
---
Add support to customize the about card icon links via `EntityIconLinkBlueprint` and provide a default catalog view catalog source, launch scaffolder template and read techdocs docs icon links extensions.
**BREAKING ALPHA**
The `Scaffolder` launch template and `TechDocs` read documentation icons have been extracted from the default `Catalog` about card links and are now provided respectively by the `Scaffolder` and `TechDocs` plugins in the new frontend system. It means that they will not be available unless you install the `TechDocs` and `Scaffolder` plugins. Also If you are using translation for these icon link titles other than the default, you should now translate them using the scaffolder translation reference or the TechDocs translation reference (the translation keys are still the same, `aboutCard.viewTechdocs` and `aboutCard.launchTemplate`).
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-org': patch
---
Org plugin support i18n
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-gerrit': patch
---
Migrating to use new format for actions
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-user-settings': patch
---
Add some translation to user-setting plugin
+6
View File
@@ -0,0 +1,6 @@
---
'@backstage/plugin-techdocs': minor
---
**New Frontend System Only:**
The `TechDocs` plugin is now responsible for providing an entity icon link extension to read documentation from the catalog entity page.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-backend-module-gitlab': minor
---
**BREAKING CHANGE**: User and Group discovery will default to ingesting all users in sub groups that belong to the specified root group in config. Disable by setting `restrictUsersToGroup: true` in app-config under your module settings.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
Switched to using the `ModuleFederationPlugin` from `@module-federation/enhanced/rspack` for Rspack, rather than the built-in one.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-sentry': patch
---
Migrate to new actions format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-backend': patch
---
You can now specify an optional value when applying the `HAS_LABEL` permission rule, similar to the `HAS_ANNOTATION` permission rule.
+8
View File
@@ -0,0 +1,8 @@
---
'@backstage/plugin-scaffolder-backend-module-notifications': patch
'@backstage/plugin-notifications-backend': patch
'@backstage/plugin-notifications-common': patch
'@backstage/plugin-notifications': patch
---
Adds ability for user to turn on/off notifications for specific topics within an origin.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-search-backend-module-techdocs': patch
---
Exports the default document collator for use in document transformation during search indexing.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-notifications': patch
---
Removed `octokit` dependency as it was not being used
+49
View File
@@ -0,0 +1,49 @@
---
'@backstage/plugin-catalog-react': minor
---
Introduces a new `EntityIconLinkBlueprint` that customizes the `About` card icon links on the `Catalog` entity page.
The blueprint currently accepts a `useProps` hook as `param` and this function returns the following props that will be passed to the icon link component:
| Name | Description | Type | Default Value |
| ---------- | --------------------------------------------------- | ------------- | ------------- |
| `icon` | The icon to display. | `JSX.Element` | N/A |
| `label` | The label for the element. | `string` | N/A |
| `title` | The title for the element. | `string` | N/A |
| `disabled` | Whether the element is disabled. | `boolean` | `false` |
| `href` | The URL to navigate to when the element is clicked. | `string` | N/A |
| `onClick` | A function to call when the element is clicked. | `() => void` | N/A |
Here is an usage example:
```tsx
import { EntityIconLinkBlueprint } from '@backstage/plugin-catalog-react/alpha';
//...
EntityIconLinkBlueprint.make({
name: 'my-icon-link',
params: {
useProps() {
const { t } = useTranslationRef(myIconLinkTranslationRef);
return {
label: t('myIconLink.label'),
icon: <MyIconLinkIcon />,
href: '/my-plugin',
};
},
},
});
```
Additionally, the `app-config.yaml` file allows you to override some of the default icon link parameters, including `label` and `title` values. Here's how to set them:
```yaml
app:
extensions:
- entity-icon-link:my-plugin/my-icon-link:
config:
label: 'My Custom Icon Link label'
```
Finally, you can disable all links if you want to hide the About card header completely (useful, for example, when links are displayed on separate cards). The header is hidden when no icon links extensions are enabled.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-rails': patch
---
Migrate to new actions format
+29
View File
@@ -0,0 +1,29 @@
---
'@backstage/frontend-plugin-api': patch
---
Added a new optional `info` option to `createFrontendPlugin` that lets you provide a loaders for different sources of metadata information about the plugin.
There are two available loaders. The first one is `info.packageJson`, which can be used to point to a `package.json` file for the plugin. This is recommended for any plugin that is defined within its own package, especially all plugins that are published to a package registry. Typical usage looks like this:
```ts
export default createFrontendPlugin({
pluginId: '...',
info: {
packageJson: () => import('../package.json'),
},
});
```
The second loader is `info.manifest`, which can be used to point to an opaque plugin manifest. This **MUST ONLY** be used by plugins that are intended for use within a single organization. Plugins that are published to an open package registry should **NOT** use this loader. The loader is useful for adding additional internal metadata associated with the plugin, and it is up to the Backstage app to decide how these manifests are parsed and used. The default manifest parser in an app created with `createApp` from `@backstage/frontend-defaults` is able to parse the default `catalog-info.yaml` format and built-in fields such as `spec.owner`.
Typical usage looks like this:
```ts
export default createFrontendPlugin({
pluginId: '...',
info: {
manifest: () => import('../catalog-info.yaml'),
},
});
```
+51 -1
View File
@@ -201,5 +201,55 @@
"@backstage/plugin-user-settings-backend": "0.3.2",
"@backstage/plugin-user-settings-common": "0.0.1"
},
"changesets": []
"changesets": [
"bitter-pants-watch",
"brave-facts-pay",
"cold-meals-like",
"create-app-1748956288",
"curvy-peaches-relate",
"dull-buttons-press",
"eight-pigs-post",
"eight-planets-see",
"evil-cooks-watch",
"famous-streets-stay",
"few-streets-accept",
"fresh-brooms-follow",
"good-paths-act",
"grumpy-dryers-act",
"honest-moles-bet",
"khaki-horses-chew",
"late-buttons-strive",
"lazy-rice-dream",
"long-suits-obey",
"mean-tigers-rush",
"new-beers-sell",
"olive-buses-serve",
"petite-candies-tan",
"puny-pillows-wave",
"red-vans-march",
"ripe-squids-sink",
"salty-worlds-float",
"scaffolder-breakages-1",
"scaffolder-breakages-2",
"scaffolder-breakages-3",
"scaffolder-deprecations-1",
"seven-beans-appear",
"shiny-bags-bet",
"six-mangos-yell",
"slow-impalas-wear",
"small-dots-march",
"smooth-eels-think",
"spotty-cases-show",
"stupid-flies-speak",
"stupid-pens-serve",
"sweet-ducks-wait",
"sweet-squids-dig",
"three-boats-sort",
"tough-heads-knock",
"true-tools-play",
"warm-taxes-show",
"wet-bars-report",
"wet-bars-reporting",
"yummy-donuts-peel"
]
}
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-plugin-api': patch
---
Added a new `useAppNode` hook, which can be used to get a reference to the `AppNode` from by the closest `ExtensionBoundary`.
+6
View File
@@ -0,0 +1,6 @@
---
'@backstage/plugin-scaffolder': minor
---
**New Frontend System Only:**
The `Scaffolder` plugin is now responsible for providing an entity icon link extension to launch templates from the catalog entity page.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-gitea': patch
---
Migrate to new actions format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
The experimental `FORCE_REACT_DEVELOPMENT` flag has been removed.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/create-app': minor
---
Add .cache directory to shipped gitignore.
+27
View File
@@ -0,0 +1,27 @@
---
'@backstage/plugin-scaffolder-backend': major
---
**BREAKING CHANGES**
Removal of deprecated re-exports from module packages.
The following functions have been re-exported from the `scaffolder-backend` plugin for quite some time, and now it's time to clean them up. They've been moved as follows:
- `createPublishAzureAction` should be imported from `@backstage/plugin-scaffolder-backend-module-azure` instead.
- `createPublishBitbucketCloudAction` should be imported from `@backstage/plugin-scaffolder-backend-module-bitbucket-cloud` instead.
- `createPublishBitbucketServerAction` and `createPublishBitbucketServerPullRequestAction` can be imported from `@backstage/plugin-scaffolder-backend-module-bitbucket-server` instead.
- `createPublishBitbucketAction` should be imported from `@backstage/plugin-scaffolder-backend-module-bitbucket` instead.
- `createPublishGerritAction` and `createPublishGerritReviewAction` can be imported from `@backstage/plugin-scaffolder-backend-module-gerrit` instead.
- `createGithubActionsDispatchAction`, `createGithubDeployKeyAction`, `createGithubEnvironmentAction`, `createGithubIssuesLabelAction`, `CreateGithubPullRequestActionOptions`, `createGithubRepoCreateAction`, `createGithubRepoPushAction`, `createGithubWebhookAction`, and `createPublishGithubAction` can be imported from `@backstage/plugin-scaffolder-backend-module-github` instead.
- `createPublishGitlabAction` should be imported from `@backstage/plugin-scaffolder-backend-module-gitlab` instead.
- `ActionContext`. `createTemplateAction`, `executeShellCommand`, `ExecuteShellCommandOptions`, `fetchContents`, `TaskSecrets`, and `TemplateAction` should be imported from `@backstage/plugin-scaffolder-node` instead.
- `ScaffolderEntitiesProcessor` should be imported from `@backstage/plugin-catalog-backend-module-scaffolder-entity-model` instead.
+7
View File
@@ -0,0 +1,7 @@
---
'@backstage/plugin-scaffolder-backend': major
---
**BREAKING ALPHA**: The `/alpha` export no longer exports the plugin. Please use `import('@backstage/plugin-scaffolder-backend')` instead as this has been removed.
**BREAKING CHANGES**: The old `createRouter` function which was used in the old backend system has been removed along with the `RouterOptions` type.
+11
View File
@@ -0,0 +1,11 @@
---
'@backstage/plugin-scaffolder-backend': major
---
**BREAKING CHANGES**
The following functions have been re-exported from the `scaffolder-backend` plugin for quite some time, and now it's time to clean them up. They've been moved as follows:
- `SerializedTask`, `SerializedTaskEvent`, `TaskBroker`, `TaskBrokerDispatchOptions`, `TaskBrokerDispatchResult`, `TaskCompletionState`, `TaskContext`, `TaskEventType`, `TaskStatus`, `TemplateFilter`, and `TemplateGlobal` should be imported from `@backstage/plugin-scaffolder-node` instead.
- The deprecated `copyWithoutRender` option has been removed from `fetch:template` action. You should rename the option to `copyWithoutTemplating` instead.
+60
View File
@@ -0,0 +1,60 @@
---
'@backstage/plugin-scaffolder-node': minor
---
**BREAKING CHANGES**
The legacy methods to define `createTemplateActions` have been replaced with the new native `zod` approaches for defining input and output schemas.
You can migrate actions that look like the following with the below examples:
```ts
// really old legacy json schema
createTemplateAction<{ repoUrl: string }, { repoOutput: string }>({
id: 'test',
schema: {
input: {
type: 'object'
required: ['repoUrl']
properties: {
repoUrl: {
type: 'string',
description: 'repository url description'
}
}
}
}
});
// old zod method
createTemplateAction({
id: 'test'
schema: {
input: {
repoUrl: z.string({ description: 'repository url description' })
}
}
})
// new method:
createTemplateAction({
id: 'test',
schema: {
input: {
repoUrl: z => z.string({ description: 'repository url description' })
}
}
})
// or for more complex zod types like unions
createTemplateAction({
id: 'test',
schema: {
input: z => z.object({
repoUrl: z.string({ description: 'repository url description' })
})
}
})
```
This breaking change also means that `logStream` has been removed entirely from `ActionsContext`, and that the `logger` is now just a `LoggerService` implementation instead. There is no replacement for the `logStream`, if you wish to still keep using a `logStream` we recommend that you create your own stream that writes to `ctx.logger` instead.
+36
View File
@@ -0,0 +1,36 @@
---
'@backstage/plugin-scaffolder-backend-module-github': minor
---
**BREAKING CHANGES**
The `createGithubEnvironmentAction` action no longer requires an `AuthService`, and now accepts a `CatalogService` instead of `CatalogClient`.
Unless you're providing your own override action to the default, this should be a non-breaking change.
You can migrate using the following if you're getting typescript errors:
```ts
import { catalogServiceRef } from '@backstage/plugin-catalog-node';
import { scaffolderActionsExtensionPoint } from '@backstage/plugin-scaffolder-node/alpha';
export const myModule = createBackendModule({
pluginId: 'scaffolder',
moduleId: 'test',
register({ registerInit }) {
registerInit({
deps: {
scaffolder: scaffolderActionsExtensionPoint,
catalog: catalogServiceRef,
},
async init({ scaffolder, catalog }) {
scaffolder.addActions(
createGithubEnvironmentAction({
catalog,
}),
);
},
});
},
});
```
+42
View File
@@ -0,0 +1,42 @@
---
'@backstage/plugin-scaffolder-backend': major
---
**BREAKING CHANGES**
- The `createBuiltinActions` method has been removed, as this should no longer be needed with the new backend system route, and was only useful when passing the default list of actions again in the old backend system. You should be able to rely on the default behaviour of the new backend system which is to merge the actions.
- The `createCatalogRegisterAction` and `createFetchCatalogEntityAction` actions no longer require an `AuthService`, and now accepts a `CatalogService` instead of `CatalogClient`.
Unless you're providing your own override action to the default, this should be a non-breaking change.
You can migrate using the following if you're getting typescript errors:
```ts
import { catalogServiceRef } from '@backstage/plugin-catalog-node';
import { scaffolderActionsExtensionPoint } from '@backstage/plugin-scaffolder-node/alpha';
export const myModule = createBackendModule({
pluginId: 'scaffolder',
moduleId: 'test',
register({ registerInit }) {
registerInit({
deps: {
scaffolder: scaffolderActionsExtensionPoint,
catalog: catalogServiceRef,
},
async init({ scaffolder, catalog }) {
scaffolder.addActions(
createCatalogRegisterAction({
catalog,
}),
createFetchCatalogEntityAction({
catalog,
integrations,
}),
);
},
});
},
});
```
+20
View File
@@ -0,0 +1,20 @@
---
'@backstage/plugin-scaffolder-backend': minor
---
**DEPRECATIONS**
The following types and implementations have been deprecated, either because they're no longer relevant, or because upcoming changes to the `scaffolder-backend` after `2.0.0` will influence the changes to these API surfaces.
- `CreateWorkerOptions`
- `DatabaseTaskStore`
- `DatabaseTaskStoreOptions`
- `TaskManager`
- `TaskStoreCreateTaskOptions`
- `TaskStoreCreateTaskResult`
- `TaskStoreEmitOptions`
- `TaskStoreListEventsOptions`
- `TaskStoreRecoverTaskOptions`
- `TaskStoreShutDownTaskOptions`
There is no current path off deprecation, these types are going to be removed and rethought with a better way to define workers in the new backend system.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-backend-module-gitlab': patch
---
Implement retry for GitLab API calls to handle rate limiting
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-bitbucket': patch
---
Migrating `bitbucket` actions to use the new `zod` format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/repo-tools': minor
---
Add support for caching the per-package output from the `package-docs` command.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-import': patch
---
Catalog import plugin full support i18n
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
Only use the caching Jest module loader for frontend packages in order to avoid breaking real ESM module imports.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-gitlab': patch
---
Support merge request labels in publish:gitlab:merge-request
+8
View File
@@ -0,0 +1,8 @@
---
'@backstage/plugin-techdocs': minor
'@backstage/plugin-techdocs-react': minor
'@backstage/plugin-catalog': minor
'@backstage/plugin-techdocs-common': patch
---
Introduced `backstage.io/techdocs-entity-path` annotation which allows deep linking into another entities TechDocs in conjunction with `backstage.io/techdocs-entity`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-backend-module-bitbucket-cloud': minor
---
**BREAKING**: `BitbucketCloudEntityProvider` now accepts a `CatalogService` instead of a `CatalogApi`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-defaults': patch
---
Forwarded the new `pluginInfoResolver` option for `createApp`.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
Updating the scaffolder action boilerplate to use new `zod` schema
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/frontend-app-api': patch
---
Implemented support for the `plugin.info()` method in specialized apps with a default resolved for `package.json` and `catalog-info.yaml`. The default resolution logic can be overridden via the `pluginInfoResolver` option to `createSpecializedApp`, and plugin-specific overrides can be applied via the new `app.pluginOverrides` key in static configuration.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
Internal refactor to combine alpha `build` and `start` modules.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/backend-test-utils': minor
---
Added mock implementations for `ActionsService` and `ActionsRegistryService`
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-cookiecutter': patch
---
Migrate using new actions format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
fix: merge eslint reports when using json format
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-backend': patch
---
Update `refresh_state_references.id` to be a big int
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend-module-bitbucket-cloud': patch
---
Fix `bitbucketCloudBranchRestrictions` API calls to accept null to prevent 400 errors for some branch restriction kinds defined.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-search-react': patch
---
SearchBar clear button support i18n
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/backend-plugin-api': minor
---
Added `coreServices.actionsRegistry` and `coreServices.actions` to allow registration of distributed actions from plugins, and the ability to invoke these actions
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/backend-defaults': patch
---
Added some default implementations for the `ActionsService` and `ActionsRegistryService` that allow registration of actions for a particular plugin.
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/canon': patch
---
Remove leftover console.log from Container component.
+67 -1
View File
@@ -80,6 +80,34 @@ jobs:
if-no-files-found: error
retention-days: 1
# Use the lower-level cache actions for the success cache, so that we can store the cache even on failed builds
- name: restore package-docs cache
uses: actions/cache/restore@5a3ec84eff668545956fd18022155c47e93e2684 # v4
with:
path: .cache/package-docs
key: ${{ runner.os }}-v${{ matrix.node-version }}-package-docs-stable-${{ github.run_id }}
restore-keys: |
${{ runner.os }}-v${{ matrix.node-version }}-package-docs-stable-
- name: build API reference (beta)
run: yarn backstage-repo-tools package-docs
- name: upload API reference (beta)
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
with:
name: stable-reference-beta
path: type-docs/
if-no-files-found: error
retention-days: 1
# Always save success cache even if there were failures, that way it can be used in re-triggered builds
- name: save package-docs cache
uses: actions/cache/save@5a3ec84eff668545956fd18022155c47e93e2684 # v4
if: always()
with:
path: .cache/package-docs
key: ${{ runner.os }}-v${{ matrix.node-version }}-package-docs-stable-${{ github.run_id }}
- name: microsite yarn install
run: yarn install --immutable
working-directory: microsite
@@ -136,6 +164,34 @@ jobs:
if-no-files-found: error
retention-days: 1
# Use the lower-level cache actions for the success cache, so that we can store the cache even on failed builds
- name: restore package-docs cache
uses: actions/cache/restore@5a3ec84eff668545956fd18022155c47e93e2684 # v4
with:
path: .cache/package-docs
key: ${{ runner.os }}-v${{ matrix.node-version }}-package-docs-${{ github.run_id }}
restore-keys: |
${{ runner.os }}-v${{ matrix.node-version }}-package-docs-
- name: build API reference (beta)
run: yarn backstage-repo-tools package-docs
- name: upload API reference (beta)
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
with:
name: next-reference-beta
path: type-docs/
if-no-files-found: error
retention-days: 1
# Always save success cache even if there were failures, that way it can be used in re-triggered builds
- name: save package-docs cache
uses: actions/cache/save@5a3ec84eff668545956fd18022155c47e93e2684 # v4
if: always()
with:
path: .cache/package-docs
key: ${{ runner.os }}-v${{ matrix.node-version }}-package-docs-${{ github.run_id }}
# Also build and upload storybook
- name: storybook yarn install
run: yarn install --immutable
@@ -265,8 +321,18 @@ jobs:
name: storybook
path: microsite/build/storybook
- uses: actions/download-artifact@95815c38cf2ff2164869cbab79da8d1f422bc89e # v4
with:
name: stable-reference-beta
path: microsite/build/api/stable/
- uses: actions/download-artifact@95815c38cf2ff2164869cbab79da8d1f422bc89e # v4
with:
name: next-reference-beta
path: microsite/build/api/next/
- name: Check the build output
run: ls microsite/build && ls microsite/build/storybook
run: ls microsite/build && ls microsite/build/storybook && ls microsite/build/api/stable && ls microsite/build/api/next
- name: Deploy both microsite and storybook to gh-pages
uses: JamesIves/github-pages-deploy-action@6c2d9db40f9296374acc17b90404b6e8864128c8 # v4.7.3
+64
View File
@@ -85,6 +85,32 @@ jobs:
if-no-files-found: error
retention-days: 1
# Use the lower-level cache actions for the success cache, so that we can store the cache even on failed builds
- name: restore package-docs cache
uses: actions/cache/restore@5a3ec84eff668545956fd18022155c47e93e2684 # v4
with:
path: .cache/package-docs
key: ${{ runner.os }}-v${{ matrix.node-version }}-package-docs-stable-${{ github.run_id }}
restore-keys: |
${{ runner.os }}-v${{ matrix.node-version }}-package-docs-stable-
- name: build API reference (beta)
run: yarn backstage-repo-tools package-docs
- name: upload API reference (beta)
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
with:
name: stable-reference-beta
path: type-docs/
# Always save success cache even if there were failures, that way it can be used in re-triggered builds
- name: save package-docs cache
uses: actions/cache/save@5a3ec84eff668545956fd18022155c47e93e2684 # v4
if: always()
with:
path: .cache/package-docs
key: ${{ runner.os }}-v${{ matrix.node-version }}-package-docs-stable-${{ github.run_id }}
- name: microsite yarn install
run: yarn install --immutable
working-directory: microsite
@@ -140,6 +166,32 @@ jobs:
if-no-files-found: error
retention-days: 1
# Use the lower-level cache actions for the success cache, so that we can store the cache even on failed builds
- name: restore package-docs cache
uses: actions/cache/restore@5a3ec84eff668545956fd18022155c47e93e2684 # v4
with:
path: .cache/package-docs
key: ${{ runner.os }}-v${{ matrix.node-version }}-package-docs-next-${{ github.run_id }}
restore-keys: |
${{ runner.os }}-v${{ matrix.node-version }}-package-docs-next-
- name: build API reference (beta)
run: yarn backstage-repo-tools package-docs
- name: upload API reference (beta)
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
with:
name: next-reference-beta
path: type-docs/
# Always save success cache even if there were failures, that way it can be used in re-triggered builds
- name: save package-docs cache
uses: actions/cache/save@5a3ec84eff668545956fd18022155c47e93e2684 # v4
if: always()
with:
path: .cache/package-docs
key: ${{ runner.os }}-v${{ matrix.node-version }}-package-docs-next-${{ github.run_id }}
# Also build and upload storybook
- name: storybook yarn install
run: yarn install --immutable
@@ -271,3 +323,15 @@ jobs:
- name: build microsite
run: yarn build
working-directory: microsite
- name: download stable reference (beta)
uses: actions/download-artifact@95815c38cf2ff2164869cbab79da8d1f422bc89e # v4
with:
name: stable-reference-beta
path: api/stable/
- name: download next reference (beta)
uses: actions/download-artifact@95815c38cf2ff2164869cbab79da8d1f422bc89e # v4
with:
name: next-reference-beta
path: api/next/
+1
View File
@@ -284,3 +284,4 @@ _You can do this by using the [Adopter form](https://info.backstage.spotify.com/
| [Scalepoint](https://scalepoint.com) | [Yuriy Ostapenko](https://github.com/yuriyostapenko), [Dmytro Pasko](https://github.com/dimapasko), [Yuri Sedykh ](https://github.com/yuiri-sedykh), [Bartosz Wisniewski](https://github.com/Epgor) | Internal Developer Portal: Software Catalog with infrastructure resources and dependencies, Software Templates, TechDocs, Tech Radar, Kubernetes and Observability, as well as custom CI/CD components |
| [VR](https://www.vr.com.br) | [Felipe Gomes](https://www.linkedin.com/in/felipe-gomes-da-silva), [Tiago Garcia](https://www.linkedin.com/in/tiago-garcia-6301a925) | Internal portal for development squads, service catalog, documentation hub, and application mapping for the entire company ecosystem, simplifying cloud infrastructure construction through templates. |
| [Plata](https://platacard.mx/en) | [Shamil Ganiev](https://github.com/ganievs) | Internal Developer Portal for the whole engineering team |
| [Syngenta Digital](https://www.syngentadigital.com) | [Bitan Mallick](https://www.linkedin.com/in/bitanmallick) | Internal developer portal, designed to empower developers and streamline workflows. We use software catalog, tech-radar, software templates, tech-docs and various custom plugins to ensure an efficient and collaborative development experience. |
+10 -3
View File
@@ -26,6 +26,7 @@ These labels indicate what is needed to move an issue forward before it can be a
- `needs:bep` - The issue is an advanced addition that needs a [Backstage Enhancement Proposal](./beps/README.md).
- `needs:direction` - The issue needs direction from the owners of the area.
- `needs:discussion` - The way forward for this issue is unclear and it needs further discussion with the author and other participants.
- `needs:more-info` - The issue needs more information from the author.
- `needs:motivation` - It is not clear why this change is needed. The author should provide motivation for the change, for instance by giving examples of concrete use cases or scenarios.
- `needs:repro` - The issue cannot be reproduced by the owners of the area. The author should provide more information to help them reproduce the issue, if possible with a minimal reproduction repository.
@@ -81,11 +82,17 @@ These labels indicate that an issue is related to specific domains of expertise.
- `domain:tooling` - Tooling and automation in Node.js and GitHub Actions.
- `domain:web` - Frontend development using TypeScript and React.
## Workflow Labels
These labels indicate a workflow status for the owners.
- `workflow:do-not-merge` - The Pull Request should not be merged.
- `workflow:before-release` - Should be handled before the next main-line release.
- `workflow:after-release` - Should be handled after the next main-line release.
- `workflow:after-vacations` - To be handled once the owners return from vacation.
## General Labels
- `after vacations` - To be handled once the owners return from vacation.
- `do not merge` - The pull request should not be merged.
- `fix before release` - Should be handled before the next release.
- `good first issue` - Good for new contributors.
- `stale` - The issue or pull request has not seen any activity for a while and will be closed if no further activity is seen.
- `no stale` - The issue or pull request should not be closed due to inactivity.
+5 -211
View File
@@ -64,83 +64,11 @@ backend:
# See README.md in the proxy-backend plugin for information on the configuration format
proxy:
endpoints:
'/circleci/api':
target: https://circleci.com/api/v1.1
headers:
Circle-Token: ${CIRCLECI_AUTH_TOKEN}
'/jenkins/api':
target: http://localhost:8080
headers:
Authorization: ${JENKINS_BASIC_AUTH_HEADER}
'/travisci/api':
target: https://api.travis-ci.com
changeOrigin: true
headers:
Authorization: ${TRAVISCI_AUTH_TOKEN}
travis-api-version: '3'
'/newrelic/apm/api':
target: https://api.newrelic.com/v2
headers:
X-Api-Key: ${NEW_RELIC_REST_API_KEY}
allowedHeaders:
- link
'/newrelic/api':
target: https://api.newrelic.com
headers:
X-Api-Key: ${NEW_RELIC_USER_KEY}
'/pagerduty':
target: https://api.pagerduty.com
headers:
Authorization: Token token=${PAGERDUTY_TOKEN}
'/buildkite/api':
target: https://api.buildkite.com/v2/
headers:
Authorization: ${BUILDKITE_TOKEN}
'/sentry/api':
target: https://sentry.io/api/
allowedMethods: ['GET']
headers:
Authorization: ${SENTRY_TOKEN}
'/ilert':
target: https://api.ilert.com
allowedMethods: ['GET', 'POST', 'PUT']
allowedHeaders: ['Authorization']
headers:
Authorization: ${ILERT_AUTH_HEADER}
'/airflow':
target: https://your.airflow.instance.com/api/v1
headers:
Authorization: ${AIRFLOW_BASIC_AUTH_HEADER}
'/gocd':
target: https://your.gocd.instance.com/go/api
allowedMethods: ['GET']
allowedHeaders: ['Authorization']
headers:
Authorization: Basic ${GOCD_AUTH_CREDENTIALS}
'/dynatrace':
target: https://your.dynatrace.instance.com/api/v2
headers:
Authorization: 'Api-Token ${DYNATRACE_ACCESS_TOKEN}'
'/stackstorm':
target: https://your.stackstorm.instance.com/api
headers:
St2-Api-Key: ${ST2_API_KEY}
'/puppetdb':
target: https://your.puppetdb.instance.com
organization:
name: My Company
@@ -157,46 +85,6 @@ techdocs:
publisher:
type: 'local' # Alternatives - 'googleGcs' or 'awsS3' or 'azureBlobStorage' or 'openStackSwift'. Read documentation for using alternatives.
dynatrace:
baseUrl: https://your.dynatrace.instance.com
nomad:
addr: 0.0.0.0
# Score-cards sample configuration.
scorecards:
jsonDataUrl: https://raw.githubusercontent.com/Oriflame/backstage-plugins/main/plugins/score-card/sample-data/
wikiLinkTemplate: https://link-to-wiki/{id}
sentry:
organization: my-company
rollbar:
organization: my-company
# NOTE: The rollbar-backend & accountToken key may be deprecated in the future (replaced by a proxy config)
accountToken: my-rollbar-account-token
lighthouse:
baseUrl: http://localhost:3003
kubernetes:
serviceLocatorMethod:
type: 'multiTenant'
clusterLocatorMethods:
- type: 'config'
clusters: []
kafka:
clientId: backstage
clusters:
- name: cluster
dashboardUrl: https://akhq.io/
brokers:
- localhost:9092
allure:
baseUrl: http://localhost:5050/allure-docker-service
integrations:
github:
- host: github.com
@@ -269,26 +157,6 @@ catalog:
plugins:
- catalog
- search
processors:
ldapOrg:
### Example for how to add your enterprise LDAP server
# providers:
# - target: ldaps://ds.example.net
# bind:
# dn: uid=ldap-reader-user,ou=people,ou=example,dc=example,dc=net
# secret: ${LDAP_SECRET}
# users:
# dn: ou=people,ou=example,dc=example,dc=net
# options:
# filter: (uid=*)
# map:
# description: l
# groups:
# dn: ou=access,ou=groups,ou=example,dc=example,dc=net
# options:
# filter: (&(objectClass=some-group-class)(!(groupType=email)))
locations:
# Add a location here to ingest it, for example from a URL:
#
@@ -325,13 +193,14 @@ catalog:
target: ../../plugins/scaffolder-backend/sample-templates/all-templates.yaml
rules:
- allow: [Template]
scaffolder:
# Use to customize default commit author info used when new components are created
# defaultAuthor:
# name: Scaffolder
# email: scaffolder@backstage.io
defaultAuthor:
name: Scaffolder
email: scaffolder@backstage.io
# Use to customize the default commit message when new components are created
# defaultCommitMessage: 'Initial commit'
defaultCommitMessage: 'Initial commit'
auth:
### Add auth.keyStore.provider to more granularly control how to store JWK data when running
@@ -422,80 +291,5 @@ auth:
myproxy: {}
guest: {}
costInsights:
engineerCost: 200000
engineerThreshold: 0.5
products:
computeEngine:
name: Compute Engine
icon: compute
cloudDataflow:
name: Cloud Dataflow
icon: data
cloudStorage:
name: Cloud Storage
icon: storage
bigQuery:
name: BigQuery
icon: search
events:
name: Events
icon: data
metrics:
DAU:
name: Daily Active Users
default: true
MSC:
name: Monthly Subscribers
currencies:
engineers:
label: 'Engineers 🛠'
unit: 'engineer'
usd:
label: 'US Dollars 💵'
kind: 'USD'
unit: 'dollar'
prefix: '$'
rate: 1
carbonOffsetTons:
label: 'Carbon Offset Tons ♻️⚖️s'
kind: 'CARBON_OFFSET_TONS'
unit: 'carbon offset ton'
rate: 3.5
beers:
label: 'Beers 🍺'
kind: 'BEERS'
unit: 'beer'
rate: 4.5
pintsIceCream:
label: 'Pints of Ice Cream 🍦'
kind: 'PINTS_OF_ICE_CREAM'
unit: 'ice cream pint'
rate: 5.5
pagerDuty:
eventsBaseUrl: 'https://events.pagerduty.com/v2'
jenkins:
instances:
- name: default
baseUrl: https://jenkins.example.com
username: backstage-bot
apiKey: 123456789abcdef0123456789abcedf012
azureDevOps:
host: dev.azure.com
token: my-token
organization: my-company
apacheAirflow:
baseUrl: https://your.airflow.instance.com
gocd:
baseUrl: https://your.gocd.instance.com
stackstorm:
webUrl: https://your.stackstorm.webui.instance.com
permission:
enabled: true
+57 -36
View File
@@ -1,56 +1,77 @@
# Releases
## Version 0.4.0
### Main updates
- ✨ Add new `Tab` component - [#29996](https://github.com/backstage/backstage/pull/29996)
- ✨ Add `truncate` prop to `Text` and `Heading` - [#29988](https://github.com/backstage/backstage/pull/29988)
- ✨ Add combobox option to `Menu` - [#29986](https://github.com/backstage/backstage/pull/29986)
- ✨ Add icon prop on `TextField` - [#29820](https://github.com/backstage/backstage/pull/29820)
- Improve icon props on `Button` and `IconButton` - [#29667](https://github.com/backstage/backstage/pull/29667)
- Improve the way we treat custom render on `Text` and `Heading` - [#29989](https://github.com/backstage/backstage/pull/29989)
- Improve `Menu` styles - [#29986](https://github.com/backstage/backstage/pull/29986)
- Improve `TextField` styles - [#29974](https://github.com/backstage/backstage/pull/29974)
- Improve clear button on `TextField` - [#29878](https://github.com/backstage/backstage/pull/29878)
### Notable fixes
- Fix spacing props on all layout components - [#30013](https://github.com/backstage/backstage/pull/30013)
- Fix - Pin Base UI version - [#29782](https://github.com/backstage/backstage/pull/29782)
- Fix - Clicking `Select` label moves focus to trigger - [#29755](https://github.com/backstage/backstage/pull/29755)
- Fix `DataTable.Pagination` count issue - [#29688](https://github.com/backstage/backstage/pull/29688)
## Version 0.3.0
### Main updates
- Add `DataTable` component - ([#29484](https://github.com/backstage/backstage/pull/29484), [#29603](https://github.com/backstage/backstage/pull/29603))
- Add `Select` component - ([#29440](https://github.com/backstage/backstage/pull/29440))
- Add `Avatar` component - ([#29594](https://github.com/backstage/backstage/pull/29594))
- Add `Collapsible` component - ([#29617](https://github.com/backstage/backstage/pull/29617))
- Add `TextField` component instead of `Field` + `Input` - ([#29364](https://github.com/backstage/backstage/pull/29364))
- Add `TableCellProfile` - ([#29600](https://github.com/backstage/backstage/pull/29600))
- Add breakpoint hooks - `up()` and `down()` - ([#29564](https://github.com/backstage/backstage/pull/29564))
- Add gray scale css tokens - ([#29543](https://github.com/backstage/backstage/pull/29543))
- Update CSS styling API using `[data-___]` instead of class names for props - ([#29560](https://github.com/backstage/backstage/pull/29560))
- Update `Checkbox` dark mode - ([#29544](https://github.com/backstage/backstage/pull/29544))
- Update `Container` styles - ([#29475](https://github.com/backstage/backstage/pull/29475))
- Update `Menu` styles - ([#29351](https://github.com/backstage/backstage/pull/29351))
- Fix `Select` styles on small sizes + with long option names - ([#29545](https://github.com/backstage/backstage/pull/29545))
- Fix render prop on `Link` - ([#29247](https://github.com/backstage/backstage/pull/29247))
- Remove `Field` from `TextField` + `Select` - ([#29482](https://github.com/backstage/backstage/pull/29482))
- Update `textDecoration` to `none` on `Text` / `Heading` - ([#29357](https://github.com/backstage/backstage/pull/29357))
- Add `DataTable` component - [#29484](https://github.com/backstage/backstage/pull/29484), [#29603](https://github.com/backstage/backstage/pull/29603)
- Add `Select` component - [#29440](https://github.com/backstage/backstage/pull/29440)
- Add `Avatar` component - [#29594](https://github.com/backstage/backstage/pull/29594)
- Add `Collapsible` component - [#29617](https://github.com/backstage/backstage/pull/29617)
- Add `TextField` component instead of `Field` + `Input` - [#29364](https://github.com/backstage/backstage/pull/29364)
- Add `TableCellProfile` - [#29600](https://github.com/backstage/backstage/pull/29600)
- Add breakpoint hooks - `up()` and `down()` - [#29564](https://github.com/backstage/backstage/pull/29564)
- Add gray scale css tokens - [#29543](https://github.com/backstage/backstage/pull/29543)
- Update CSS styling API using `[data-___]` instead of class names for props - [#29560](https://github.com/backstage/backstage/pull/29560)
- Update `Checkbox` dark mode - [#29544](https://github.com/backstage/backstage/pull/29544)
- Update `Container` styles - [#29475](https://github.com/backstage/backstage/pull/29475)
- Update `Menu` styles - [#29351](https://github.com/backstage/backstage/pull/29351)
- Fix `Select` styles on small sizes + with long option names - [#29545](https://github.com/backstage/backstage/pull/29545)
- Fix render prop on `Link` - [#29247](https://github.com/backstage/backstage/pull/29247)
- Remove `Field` from `TextField` + `Select` - [#29482](https://github.com/backstage/backstage/pull/29482)
- Update `textDecoration` to `none` on `Text` / `Heading` - [#29357](https://github.com/backstage/backstage/pull/29357)
### Notable fixes
- Docs - Use stories from Storybook for all examples in Nextjs - ([#29306](https://github.com/backstage/backstage/pull/29306))
- Docs - Add release page (this one 🤗) - ([#29461](https://github.com/backstage/backstage/pull/29461))
- Docs - Add docs for Menu, Link - ([#29576](https://github.com/backstage/backstage/pull/29576))
- Fix CSS watch mode - ([#29352](https://github.com/backstage/backstage/pull/29352))
- Docs - Use stories from Storybook for all examples in Nextjs - [#29306](https://github.com/backstage/backstage/pull/29306)
- Docs - Add release page (this one 🤗) - [#29461](https://github.com/backstage/backstage/pull/29461)
- Docs - Add docs for Menu, Link - [#29576](https://github.com/backstage/backstage/pull/29576)
- Fix CSS watch mode - [#29352](https://github.com/backstage/backstage/pull/29352)
## Version 0.2.0
### Main updates
- New `Tooltip` component ([#29241](https://github.com/backstage/backstage/pull/29241))
- New `Menu` component. ([#29151](https://github.com/backstage/backstage/pull/29151))
- New `IconButton` component. ([#29239](https://github.com/backstage/backstage/pull/29239))
- New `ScrollArea` component. ([#29240](https://github.com/backstage/backstage/pull/29240))
- Improve `Button` & `Checkbox` styles. ([#29127](https://github.com/backstage/backstage/pull/29127)) ([#28789](https://github.com/backstage/backstage/pull/28789))
- Improve `Text` styles. ([#29200](https://github.com/backstage/backstage/pull/29200))
- Renamed `CanonProvider` to `IconProvider`. ([#29002](https://github.com/backstage/backstage/pull/29002))
- Added about 40+ new icons. ([#29264](https://github.com/backstage/backstage/pull/29264))
- Simplified styling into a unique styles.css file ([#29199](https://github.com/backstage/backstage/pull/29199))
- Added Canon styles to Backstage ([#29137](https://github.com/backstage/backstage/pull/29137))
- Update global CSS tokens ([#28804](https://github.com/backstage/backstage/pull/28804))
- Merge Stack + Inline into Flex ([#28634](https://github.com/backstage/backstage/pull/28634))
- New `Tooltip` component - [#29241](https://github.com/backstage/backstage/pull/29241)
- New `Menu` component - [#29151](https://github.com/backstage/backstage/pull/29151)
- New `IconButton` component - [#29239](https://github.com/backstage/backstage/pull/29239)
- New `ScrollArea` component - [#29240](https://github.com/backstage/backstage/pull/29240)
- Improve `Button` & `Checkbox` styles - [#29127](https://github.com/backstage/backstage/pull/29127), [#28789](https://github.com/backstage/backstage/pull/28789)
- Improve `Text` styles - [#29200](https://github.com/backstage/backstage/pull/29200)
- Renamed `CanonProvider` to `IconProvider` - [#29002](https://github.com/backstage/backstage/pull/29002)
- Added about 40+ new icons - [#29264](https://github.com/backstage/backstage/pull/29264)
- Simplified styling into a unique styles.css file - [#29199](https://github.com/backstage/backstage/pull/29199)
- Added Canon styles to Backstage - [#29137](https://github.com/backstage/backstage/pull/29137)
- Update global CSS tokens - [#28804](https://github.com/backstage/backstage/pull/28804)
- Merge Stack + Inline into Flex - [#28634](https://github.com/backstage/backstage/pull/28634)
### Notable fixes:
- Improve `Button` types. ([#29205](https://github.com/backstage/backstage/pull/29205))
- Move font weight and family back to each components ([#28972](https://github.com/backstage/backstage/pull/28972))
- Fix custom values in spacing props ([#28770](https://github.com/backstage/backstage/pull/28770))
- Multiple updates on the Canon Docs site ([#28760](https://github.com/backstage/backstage/pull/28760)) ([#28591](https://github.com/backstage/backstage/pull/28591))
- Improve `Button` types - [#29205](https://github.com/backstage/backstage/pull/29205)
- Move font weight and family back to each components - [#28972](https://github.com/backstage/backstage/pull/28972)
- Fix custom values in spacing props - [#28770](https://github.com/backstage/backstage/pull/28770)
- Multiple updates on the Canon Docs site - [#28760](https://github.com/backstage/backstage/pull/28760), [#28591](https://github.com/backstage/backstage/pull/28591)
## Version 0.1.0
@@ -80,11 +80,11 @@ const Content = () => {
const Line = ({ content, title }: { content: ReactNode; title: string }) => {
return (
<Grid gap={{ xs: '2', md: '4' }}>
<Grid.Root gap={{ xs: '2', md: '4' }}>
<Grid.Item colSpan="2">
<Text>{title}</Text>
</Grid.Item>
<Grid.Item colSpan="10">{content}</Grid.Item>
</Grid>
</Grid.Root>
);
};
+22
View File
@@ -203,6 +203,28 @@ or the
[`AwsEKSClusterProcessor`](https://backstage.io/docs/reference/plugin-catalog-backend-module-aws.awseksclusterprocessor/)
to automatically update the set of clusters tracked by Backstage.
For this method to work any entity that would be using this `Resource` to help drive the Kubernetes details in the Catalog's Entity pages needs to have a `dependsOn` relationship setup. Here's a quick example:
```yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
annotations:
backstage.io/kubernetes-id: dice-roller
backstage.io/kubernetes-namespace: default
name: dice-roller
description: It rolls dice
tags:
- go
spec:
type: service
lifecycle: production
owner: guest
dependsOn: ['resource:my-cluster']
```
This example assumes it's using the default namespace, if that's not the case for you then make sure to include it like this: `resource:my-namespace/my-cluster`.
#### `config`
This cluster locator method will read cluster information from your app-config
@@ -182,7 +182,7 @@ export default createPlugin({
})
```
Here is the `plugins/techdocs/alpha.tsx` final version, and you can also take a look at the [actual implementation](https://github.com/backstage/backstage/blob/master/plugins/techdocs/src/alpha.tsx) of a custom `TechDocs` search result item:
Here is the `plugins/techdocs/alpha/index.tsx` final version, and you can also take a look at the [actual implementation](https://github.com/backstage/backstage/blob/master/plugins/techdocs/src/alpha/index.tsx) of a custom `TechDocs` search result item:
```tsx
// plugins/techdocs/alpha.tsx
@@ -115,6 +115,20 @@ the TechDocs in the TechDocs page or needing multiple builds of the same docs.
This is for situations where you have complex systems where they share a single repo, and likely a single TechDoc location.
### backstage.io/techdocs-entity-path
```yaml
# Example:
metadata:
annotations:
backstage.io/techdocs-entity: component:default/example
backstage.io/techdocs-entity-path: /path/to/this/component
```
The value of this annotation informs of the path to this component's TechDocs within an external entity that owns the TechDocs.
In conjunction with [backstage.io/techdocs-entity](#backstageiotechdocs-entity) this allows for deep linking into the TechDocs of
another entity, not just linking to the root of another entities TechDocs.
### backstage.io/view-url, backstage.io/edit-url
```yaml
+29
View File
@@ -942,6 +942,35 @@ metadata:
backstage.io/techdocs-entity: system:default/example
```
### Deep linking into TechDocs
The `backstage.io/techdocs-entity-path` annotation can be use to deep link into a specific page within the components TechDocs.
This can be used in conjunction with `backstage.io/techdocs-entity` or standalone.
```yaml
apiVersion: backstage.io/v1alpha1
kind: System
metadata:
name: example
namespace: default
title: Example
description: This is the parent entity
annotations:
backstage.io/techdocs-ref: dir:.
---
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: example-platfrom
title: Example Application Platform
namespace: default
description: This is the child entity
annotations:
backstage.io/techdocs-entity: system:default/example
backstage.io/techdocs-entity-path: /path/to/component/docs
```
## How to resolve broken links from moved or renamed pages in your documentation site
TechDocs supports using the [mkdocs-redirects](https://github.com/mkdocs/mkdocs-redirects/tree/master) plugin to create a redirect map for any TechDocs site. This allows broken links from renamed or moved pages in your site to be redirected to their specified replacement.
@@ -77,3 +77,98 @@ app:
```
Note that you do not need to manually exclude packages that you also import explicitly in code, since plugin instances are deduplicated by the app. You will never end up with duplicate plugin installations except if they are in fact two different plugin instances with different IDs.
## Plugin Info Resolution
When a plugin is installed in an app it may provide sources of information about the plugin that can be useful to end users and admins. This includes things like what version of a plugin is running, what team owns the plugin, and who to contact for support. You can read more about how the plugins provide this information in the [plugins `info` option section](./15-plugins.md#info).
By default the app will pick a few common fields from `package.json` files, and assume that the opaque manifests are `catalog-info.yaml` files that some information can be gathered from too. This information will then be available via the `info()` method on plugin instances, returning a structure of the `FrontendPluginInfo` type.
### Extending Plugin Info
The default plugin info is intended as a base to build upon. As part of setting up an app you can both customize the way that the plugin info is resolved, as well as extend the `FrontendPluginInfo` type to include more information.
In order to extend the `FrontendPluginInfo` type you use [TypeScript module augmentation](https://www.typescriptlang.org/docs/handbook/declaration-merging.html#module-augmentation). This makes it possible to extend the `FrontendPluginInfo` interface with additional fields, which you can then add custom resolution logic for as well as access within the app. For example, you might add a `slackChannel` field as follows:
```ts
declare module '@backstage/frontend-plugin-api' {
interface FrontendPluginInfo {
/**
* The slack channel to use for support requests for this plugin.
*/
slackChannel?: string;
}
}
```
### Customizing Plugin Info Resolution
With the new `slackChannel` field in place, we now need to provide a custom resolver that knows how to extract this information from the plugin information sources. This is done by passing a custom `pluginInfoResolver` to `createApp`, which in our example is declared like this:
```ts title="pluginInfoResolver.ts"
import { createPluginInfoResolver } from '@backstage/frontend-plugin-api';
// It is recommended to keep the above module augmentation in this file too
export const pluginInfoResolver: FrontendPluginInfoResolver = async ctx => {
// In our particular example app we assume that all plugin manifests are catalog-info.yaml files
const manifest = (await ctx.manifest?.()) as Entity | undefined;
// Call the default resolver to populate common fields
const { info } = await ctx.defaultResolver({
packageJson: await ctx.packageJson(),
manifest: manifest,
});
// In this example the catalog model has been extended with a metadata.slackChannel field
const slackChannel = manifest?.metadata?.slackChannel?.toString();
if (slackChannel) {
info.slackChannel = slackChannel;
info.links = [
...(info.links ?? []),
{
title: 'Slack Channel',
url: `https://our-workspace.enterprise.slack.com/archives/${slackChannel}`,
},
];
}
return { info };
};
```
And included in the app as follows:
```ts title="App.tsx"
import { pluginInfoResolver } from './pluginInfoResolver';
const app = createApp({
pluginInfoResolver,
// ... other options
});
```
### Overriding Plugin Info
Another way to customize the plugin info is to use the `app.pluginOverrides` static configuration key. These overrides are applied after the plugin info has been resolved as a final step before making it available to users. These overrides are particularly useful to override information in third-party plugins. For example, if your organization has an individual team that is responsible for the maintenance of the Software Catalog, you might configure the following override:
```yaml
app:
pluginOverrides:
- match:
pluginId: catalog
info:
ownerEntityRefs: [catalog-owners]
```
You can match on both the `pluginId` and/or `packageName` of the plugin, although the `packageName` will only be supported if the plugin provides an loader for the `package.json` file. Using `/<pattern>/` you are also able to use a regex pattern for this matching. For example, if you wanted to override the owner for all plugins from the `@acme` namespace, you could do the following:
```yaml
app:
pluginOverrides:
- match:
packageName: /@acme/.*/
info:
ownerEntityRefs: [acme-owners]
```
@@ -53,6 +53,35 @@ These are the routes that the plugin exposes to the app. The `routes` option dec
This is a list of feature flag declarations that your plugin provides to the app. This makes sure that the feature flags are correctly registered and can be toggled in the app. To read a feature flag you can use the feature flags [Utility API](../architecture/33-utility-apis.md), accessible via `featureFlagsApiRef`.
### `info` option
This options is used to provide loaders for different sources of information about the plugin that may be useful to users and admins. The two available loaders are `packageJson` and `manifest`, and a plugin can use either or both as needed. The resulting information is available via the `info()` method on the plugin instance once it is installed in an app, but it is up to each app to decide how to derive the information from the provided sources.
The `info.packageJson` loader **MUST** be used by all plugins that are implemented within their own package, and it should load the `package.json` file for the plugin package. Typical usage looks like this:
```ts
export default createFrontendPlugin({
pluginId: 'my-plugin',
info: {
packageJson: () => import('../package.json'),
},
extensions: [...],
});
```
The `info.manifest` loader is used to point to an opaque plugin manifest. This **MUST ONLY** be used by plugins that are intended for use within a single organization. Plugins that are published to an open package registry should **NOT** use this loader. The loader is useful for adding additional internal metadata associated with the plugin, and it is up to the Backstage app to decide how these manifests are parsed and used. The default manifest parser in an app created with `createApp` from `@backstage/frontend-defaults` is able to parse the default `catalog-info.yaml` format and built-in fields such as `metadata.links` and `spec.owner`.
Typical usage looks like this:
```ts
export default createFrontendPlugin({
pluginId: '...',
info: {
manifest: () => import('../catalog-info.yaml'),
},
});
```
## Installing a Plugin in an App
A plugin instance is considered a frontend feature and can be installed directly in any Backstage frontend app. See the [app documentation](./10-app.md) for more information about the different ways in which you can install new features in an app.
Binary file not shown.

Before

Width:  |  Height:  |  Size: 62 KiB

After

Width:  |  Height:  |  Size: 263 KiB

File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff
+2 -1
View File
@@ -65,7 +65,8 @@ In your `.vscode/launch.json`, add a new entry with the following,
"runtimeExecutable": "yarn", // Specifies the runtime to execute the application. In this case, it uses `yarn` to run the script.
"args": ["start", "--inspect"], // Arguments passed to the `yarn` command. Here, it runs `yarn start` with the `--inspect` flag to enable debugging.
"skipFiles": ["<node_internals>/**"], // Tells the debugger to skip stepping into Node.js internal files during debugging.
"console": "integratedTerminal" // Specifies that the debugger should use the integrated terminal for input/output.
"console": "integratedTerminal", // Specifies that the debugger should use the integrated terminal for input/output.
"experimentalNetworking": "off" // Since Node.js 22.15.0 an additional parameter --experimental-network-inspection is added but currently not supported by Yarn
}
]
}
+40 -4
View File
@@ -4,7 +4,7 @@ title: Setup OpenTelemetry
description: Tutorial to setup OpenTelemetry metrics and traces exporters in Backstage
---
Backstage uses [OpenTelemetery](https://opentelemetry.io/) to instrument its components by reporting traces and metrics.
Backstage uses [OpenTelemetry](https://opentelemetry.io/) to instrument its components by reporting traces and metrics.
This tutorial shows how to setup exporters in your Backstage backend package. For demonstration purposes we will use a Prometheus exporter, but you can adjust your solution to use another one that suits your needs; see for example the article on [OTLP exporters](https://opentelemetry.io/docs/instrumentation/js/exporters/).
@@ -26,7 +26,7 @@ yarn --cwd packages/backend add \
In your `packages/backend/src` folder, create an `instrumentation.js` file.
```typescript title="in packages/backend/src/instrumentation.js"
```js title="in packages/backend/src/instrumentation.js"
// Prevent from running more than once (due to worker threads)
const { isMainThread } = require('node:worker_threads');
@@ -52,6 +52,42 @@ if (isMainThread) {
You probably won't need all of the instrumentation inside `getNodeAutoInstrumentations()` so make sure to
check the [documentation](https://www.npmjs.com/package/@opentelemetry/auto-instrumentations-node) and tweak it properly.
### Views
The default histogram buckets for OpenTelemetry are in milliseconds, but the histograms that are created for Catalog processing emit metrics in second. You might want to adjust this to what fits your need. To do this you can use the [Views feature](https://opentelemetry.io/docs/concepts/signals/metrics/#views) like this:
```js
const prometheus = new PrometheusExporter();
const sdk = new NodeSDK({
metricReader: prometheus,
views: [
new View({
instrumentName: 'catalog.test',
aggregation: new ExplicitBucketHistogramAggregation([
0.01, 0.1, 0.5, 1, 5, 10, 25, 50, 100, 500, 1000,
]),
}),
],
});
```
The above will make all the histogram buckets use the same config. If you would like to take a more targeted approach you can do this:
```js
const prometheus = new PrometheusExporter();
const sdk = new NodeSDK({
metricReader: prometheus,
views: [
new View({
instrumentName: 'catalog.test',
aggregation: new ExplicitBucketHistogramAggregation([
0, 0.01, 0.05, 0.1, 0.25, 0.5, 1, 2, 5, 10, 30, 60, 120, 300, 1000,
]),
}),
],
});
```
## Local Development Setup
It's important to setup the NodeSDK and the automatic instrumentation **before**
@@ -67,13 +103,13 @@ For local development, you can add the required flag in your `packages/backend/p
...
```
You can now start your Backstage instance as usual, using `yarn start`.
You can now start your Backstage instance as usual, using `yarn start` and you'll be able to see your metrics at: <http://localhost:9464/metrics>
## Production Setup
In your `.dockerignore`, add this line:
```
```text
!packages/backend/src/instrumentation.js
```
@@ -0,0 +1,63 @@
---
title: 'From Zero to Maintainer: My Open Source Journey with Backstage'
author: Kashish Mittal, Red Hat
authorURL: https://github.com/04kash
authorImageURL: https://avatars.githubusercontent.com/u/113269381?v=4
---
My path to becoming a maintainer in the Backstage project wasnt paved with years of prior open source experience. As a student interning at Red Hat, I started with a relatively fresh perspective. This is the story of that journey how I navigated the complexities of Backstage, with the support of its community, allowing me to grow and learn, and how open source can empower anyone to do the same. Whether youre new to open source or a seasoned developer, I believe youll find something valuable here. For those just starting out, I hope this inspires you to take that first step. And for experienced developers, I hope this offers a fresh perspective a look at how a new contributor navigates a complex project, and perhaps, a reminder of our own beginnings.
This journey wasnt made in a single leap, but through a series of progressive stages. Ill walk you through these stages, highlighting the key learnings and contributions along the way.
![The Stages of my Journey](assets/2025-05-12/stages.png)
{/* truncate */}
## Stage 1: Laying the foundation
![Getting Familiar with the Backstage Tech Stack](assets/2025-05-12/tech_stack.png)
When I first encountered Backstage, I wasnt deeply familiar with the tech stack it relied on — Node.js, TypeScript, and React. My only exposure previously had been through hackathons, where the focus is speed over deep understanding. Another major hurdle was Git. Up until that point, I had mainly used GitHub Desktop, rarely venturing into the command line or advanced Git concepts. Realizing that effective contribution required a deeper understanding, I dedicated a week to intensively reviewing these core technologies.
But that wasnt all. I wanted to see Backstage in action, to really grasp what it was all about. Thats when I came across the [Spotify Learning Path for Backstage](https://backstage.spotify.com/learn/). Specifically, the [“Standing up Backstage”](https://backstage.spotify.com/learn/standing-up-backstage/) section was incredibly useful. It walked me through setting up a local running instance with a Postgres database and GitHub authentication. From there, I explored the Backstage documentation and experimented with adding features to my local instance. Honestly, for me, this stage was all about building confidence. It was about facing my knowledge gaps head-on and taking the time to learn.
## Stage 2: First contributions
![First contributions to Backstage: learning the process and connecting with the community](assets/2025-05-12/first_contributions.png)
With my foundational skills in place, it was time to take the leap and make my first contributions to Backstage. [My first pull request](https://github.com/backstage/community-plugins/pull/497) (PR) was quite simple — fixing broken links in the documentation. This seemingly minor fix was my first step, and it paved the way for more substantial contributions. It helped me to get comfortable with the contributing process, learn how to submit a PR, and understand the review workflow. After that, I started looking for open issues in the [community-plugins repository](https://github.com/backstage/community-plugins). I found an issue about [linking npm releases of plugins to specific Git commits](https://github.com/backstage/community-plugins/issues/489) — a task that pushed me outside my comfort zone once again. At the time, I knew very little about GitHub Actions and workflows. Learning on the fly, I relied heavily on guidance from maintainers who were incredibly welcoming.
This experience was really helpful, not just for the task itself, but also because it introduced me to key community resources like the [Backstage Discord](https://discord.com/invite/backstage-687207715902193673) and [Special Interest Groups](https://github.com/backstage/community/tree/main/sigs) (or SIGs for short). While the content of the pull requests in this stage was certainly useful, the real value came from learning the projects workflows and community processes.
## Stage 3: Making substantial contributions
As my confidence grew, so did the complexity of the contributions that I took on. Two of my first feature-related contributions were related to Catalog Permissions and the LDAP Processor.
First, with Catalog Permissions, I noticed that two endpoints in the Catalog plugin, `/analyze-location` and `/validate-entity` werent restricted by permissions, posing a security risk. To address this, I needed a deep understanding of Backstages permissions system. I spent a lot of time reading through documentation and existing code, and asking questions on Discord. When I had [a PR](https://github.com/backstage/backstage/pull/25924) ready, I went to the Framework SIG meetings to discuss my implementation and to make sure that I was on the same page as the maintainers. Following this process, my PR was successfully merged!
Shortly after, I tackled an open issue with the [LDAP processor](https://github.com/backstage/backstage/issues/26225). This issue highlighted a problem where Backstage couldnt correctly map user-group relationships with certain LDAP server configurations that used attribute names that were different from the ones hardcoded within the plugin. I implemented [a solution](https://github.com/backstage/backstage/pull/26511) that allowed users to override these default values. Testing against a real LDAP instance wasnt something I could do locally, but the original issue reporter stepped in, validating my changes in their environment. It was a beautiful example of open source collaboration in action.
![My first commits in the backstage CHANGELOG](assets/2025-05-12/changelog.png)
_My first commits in the backstage CHANGELOG_
These two tasks were a significant step up from my initial contributions. They required a deeper understanding of Backstages architecture and a greater level of problem-solving. Seeing my commits in the [CHANGELOG](https://backstage.io/docs/releases/v1.31.0/#new-catalog-permissions) was an accomplishment I was proud of, and it solidified my confidence so I could take on even more substantial roles within the Backstage community.
## Stage 4: Becoming an active community member
![Engaging with the Open Source Community at the CNCF meetup in Toronto](assets/2025-05-12/cncf_1.jpeg)
_(Source: https://www.linkedin.com/posts/mwijay_you-totally-missed-last-nights-first-cncf-ugcPost-7311005210628235264-8BES)_
![Engaging with the Open Source Community at the CNCF meetup in Toronto](assets/2025-05-12/cncf_2.png)
_Engaging with the Open Source Community at the CNCF meetup in Toronto (Source: https://community.cncf.io/events/details/cncf-cloud-native-toronto-presents-cncf-2025-kickoff-at-shopify/)_
One of the ways I got more involved was by helping with the maintenance of the [community-plugins repository](https://github.com/backstage/community-plugins). For instance, I helped address a security vulnerability — specifically, that the `@backstage/backend-common package` relied on a vulnerable version of `jsonpath-plus` through `@kubernetes/client-node`. I proactively removed this vulnerable dependency from eight plugins, effectively safeguarding those plugins from potential risks. I also focused on improving dependency management by implementing Knip reports. These reports help us identify and remove unused dependencies, keeping the repository clean and efficient.
Beyond repository maintenance, I also began focusing on community engagement. I began reviewing pull requests regularly, helping maintain code quality and lightening the load on other maintainers. This not only deepened my understanding of the codebase but also exposed me to new features and patterns across the ecosystem. I actively participated in SIG meetings and offered guidance to fellow contributors on Discord.
This marked a turning point in my journey, as I transitioned from a contributor to an active community member. Eventually, this growing involvement led to me becoming a maintainer for the community-plugins repository. It was a fulfilling step forward, and it felt rewarding to be trusted with more responsibility in guiding the project.
## Whats next: future steps as a maintainer
![Presenting "From Zero to Contributor: My Open Source Journey with Backstage" at the CNCF 2025 Kickoff event at Shopify, Toronto](assets/2025-05-12/cncf_3.jpeg)
_Presenting "From Zero to Contributor: My Open Source Journey with Backstage" at the CNCF 2025 Kickoff event at Shopify, Toronto (Source: https://www.linkedin.com/posts/mwijay_you-totally-missed-last-nights-first-cncf-ugcPost-7311005210628235264-8BES)_
As a maintainer, my focus is on supporting others in their open source journey and improving the overall contributor experience. I actively review PRs, guide new contributors through constructive reviews, and point them to good first issues to help them get started.
Furthermore, I aim to actively contribute to the community-plugins SIG meetings, offering suggestions and participating in discussions to help guide the projects direction.
Ultimately, my goal is to help the community-plugins repository thrive and become an even more valuable resource for the Backstage community. Im excited to collaborate with fellow maintainers and contributors to achieve this vision.
My journey with Backstage has been incredibly rewarding, and Im grateful for the opportunities, support, and growth the community has given me. Im excited to continue contributing and to see where this journey takes me next.
Binary file not shown.

After

Width:  |  Height:  |  Size: 244 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 739 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.8 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 318 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 605 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 89 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 697 KiB

@@ -0,0 +1,10 @@
---
title: Daily Weather
author: Infosys Limited
authorUrl: https://github.com/Infosys
category: Utility
description: The Daily Weather Plugin for Backstage provides real-time weather information for a specified location using the Weatherstack API.
documentation: https://github.com/Infosys/daily-weather-plugin/tree/main/plugins/weather
iconUrl: https://github.com/Infosys/daily-weather-plugin/blob/main/plugins/weather/src/docs/plugin-logo.png?raw=true
npmPackageName: '@infosys_ltd/daily-weather-plugin'
addedDate: '2025-04-16'

Some files were not shown because too many files have changed in this diff Show More