Merge branch 'backstage:master' into patch-2
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-confluence-to-markdown': patch
|
||||
---
|
||||
|
||||
Migrate actions to new format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
table actions header support i18n
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/catalog-client': patch
|
||||
---
|
||||
|
||||
Fixed `CatalogClient` error responses for `refreshEntity` and `addLocation`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': patch
|
||||
---
|
||||
|
||||
Bumped create-app version.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-gitlab': patch
|
||||
---
|
||||
|
||||
Migrate to new action format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-azure': patch
|
||||
---
|
||||
|
||||
Migrating `azure` actions to using the new `zod` schema format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-bitbucket-cloud': patch
|
||||
---
|
||||
|
||||
Migrate `bitbucket-cloud` to new actions format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-github': patch
|
||||
---
|
||||
|
||||
Migrate to using new actions
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/canon': minor
|
||||
---
|
||||
|
||||
We set the default size for IconButton in Canon to be small instead of medium.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
---
|
||||
|
||||
render details for composite property schemas
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': patch
|
||||
---
|
||||
|
||||
Migrating to latest action format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-yeoman': patch
|
||||
---
|
||||
|
||||
Migrate to new actions format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/repo-tools': patch
|
||||
---
|
||||
|
||||
Add missing highlight language for the `package-docs` command.
|
||||
@@ -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
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-techdocs-module-addons-contrib': patch
|
||||
'@backstage/plugin-techdocs': patch
|
||||
---
|
||||
|
||||
Improved Keyboard accessibility in techdocs.
|
||||
@@ -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`
|
||||
@@ -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`).
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-org': patch
|
||||
---
|
||||
|
||||
Org plugin support i18n
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-gerrit': patch
|
||||
---
|
||||
|
||||
Migrating to use new format for actions
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-user-settings': patch
|
||||
---
|
||||
|
||||
Add some translation to user-setting plugin
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-sentry': patch
|
||||
---
|
||||
|
||||
Migrate to new actions format
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-search-backend-module-techdocs': patch
|
||||
---
|
||||
|
||||
Exports the default document collator for use in document transformation during search indexing.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-notifications': patch
|
||||
---
|
||||
|
||||
Removed `octokit` dependency as it was not being used
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-rails': patch
|
||||
---
|
||||
|
||||
Migrate to new actions format
|
||||
@@ -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'),
|
||||
},
|
||||
});
|
||||
```
|
||||
@@ -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"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -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`.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-gitea': patch
|
||||
---
|
||||
|
||||
Migrate to new actions format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
The experimental `FORCE_REACT_DEVELOPMENT` flag has been removed.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': minor
|
||||
---
|
||||
|
||||
Add .cache directory to shipped gitignore.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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,
|
||||
}),
|
||||
);
|
||||
},
|
||||
});
|
||||
},
|
||||
});
|
||||
```
|
||||
@@ -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,
|
||||
}),
|
||||
);
|
||||
},
|
||||
});
|
||||
},
|
||||
});
|
||||
```
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-gitlab': patch
|
||||
---
|
||||
|
||||
Implement retry for GitLab API calls to handle rate limiting
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-bitbucket': patch
|
||||
---
|
||||
|
||||
Migrating `bitbucket` actions to use the new `zod` format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/repo-tools': minor
|
||||
---
|
||||
|
||||
Add support for caching the per-package output from the `package-docs` command.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-import': patch
|
||||
---
|
||||
|
||||
Catalog import plugin full support i18n
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-gitlab': patch
|
||||
---
|
||||
|
||||
Support merge request labels in publish:gitlab:merge-request
|
||||
@@ -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`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-bitbucket-cloud': minor
|
||||
---
|
||||
|
||||
**BREAKING**: `BitbucketCloudEntityProvider` now accepts a `CatalogService` instead of a `CatalogApi`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/frontend-defaults': patch
|
||||
---
|
||||
|
||||
Forwarded the new `pluginInfoResolver` option for `createApp`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Updating the scaffolder action boilerplate to use new `zod` schema
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Internal refactor to combine alpha `build` and `start` modules.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-test-utils': minor
|
||||
---
|
||||
|
||||
Added mock implementations for `ActionsService` and `ActionsRegistryService`
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-cookiecutter': patch
|
||||
---
|
||||
|
||||
Migrate using new actions format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
fix: merge eslint reports when using json format
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
---
|
||||
|
||||
Update `refresh_state_references.id` to be a big int
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-search-react': patch
|
||||
---
|
||||
|
||||
SearchBar clear button support i18n
|
||||
@@ -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
|
||||
@@ -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.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/canon': patch
|
||||
---
|
||||
|
||||
Remove leftover console.log from Container component.
|
||||
@@ -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
|
||||
|
||||
@@ -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/
|
||||
|
||||
@@ -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. |
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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>
|
||||
);
|
||||
};
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
Before Width: | Height: | Size: 62 KiB After Width: | Height: | Size: 263 KiB |
@@ -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
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -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 wasn’t 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 you’re new to open source or a seasoned developer, I believe you’ll 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 wasn’t made in a single leap, but through a series of progressive stages. I’ll walk you through these stages, highlighting the key learnings and contributions along the way.
|
||||
|
||||

|
||||
{/* truncate */}
|
||||
|
||||
## Stage 1: Laying the foundation
|
||||
|
||||

|
||||
|
||||
When I first encountered Backstage, I wasn’t 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 wasn’t all. I wanted to see Backstage in action, to really grasp what it was all about. That’s 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
|
||||
|
||||

|
||||
|
||||
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 project’s 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` weren’t restricted by permissions, posing a security risk. To address this, I needed a deep understanding of Backstage’s 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 couldn’t 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 wasn’t 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_
|
||||
|
||||
These two tasks were a significant step up from my initial contributions. They required a deeper understanding of Backstage’s 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
|
||||
|
||||

|
||||
_(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 (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.
|
||||
|
||||
## What’s 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 (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 project’s direction.
|
||||
Ultimately, my goal is to help the community-plugins repository thrive and become an even more valuable resource for the Backstage community. I’m excited to collaborate with fellow maintainers and contributors to achieve this vision.
|
||||
|
||||
My journey with Backstage has been incredibly rewarding, and I’m grateful for the opportunities, support, and growth the community has given me. I’m excited to continue contributing and to see where this journey takes me next.
|
||||
|
After Width: | Height: | Size: 244 KiB |
|
After Width: | Height: | Size: 739 KiB |
|
After Width: | Height: | Size: 2.8 MiB |
|
After Width: | Height: | Size: 318 KiB |
|
After Width: | Height: | Size: 605 KiB |
|
After Width: | Height: | Size: 89 KiB |
|
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'
|
||||