Merge branch 'master' of github.com:jrwpatterson/backstage
This commit is contained in:
Joe Patterson
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
---
|
||||
|
||||
Basic analytics instrumentation is now in place:
|
||||
|
||||
- As users make their way through template steps, a `click` event is fired, including the step number.
|
||||
- After a user clicks "Create" a `create` event is fired, including the name of the software that was just created. The template used at creation is set on the `entityRef` context key.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-react': patch
|
||||
---
|
||||
|
||||
Both `EntityProvider` and `AsyncEntityProvider` contexts now wrap all children with an `AnalyticsContext` containing the corresponding `entityRef`; this opens up the possibility for all events underneath these contexts to be associated with and aggregated by the corresponding entity.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-techdocs': patch
|
||||
---
|
||||
|
||||
Fix logic bug that broke techdocs-cli-embedded-app
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
Set the `searchTooltip` to "Filter" to follow how the `searchPlaceholder` is set making this more consistent
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-app-api': minor
|
||||
---
|
||||
|
||||
Updated the React Router wiring to make use of the new `basename` property of the router components in React Router v6 stable. To implement this, a new optional `basename` property has been added to the `Router` app component, which can be forwarded to the concrete router implementation in order to support this new behavior. This is done by default in any app that does not have a `Router` component override.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-tech-insights': patch
|
||||
---
|
||||
|
||||
Fixed bug when sending data by Post in `runChecks` and `runBulkChecks` functions of the `TechInsightsClient` class, the default `Content-Type` used was `plain/text`
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/backend-common': minor
|
||||
---
|
||||
|
||||
**BREAKING CHANGE**: The `UrlReader` interface has been updated to require that `readUrl` is implemented. `readUrl` has previously been optional to implement but a warning has been logged when calling its predecessor `read`.
|
||||
The `read` method is now deprecated and will be removed in a future release.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-gitlab': patch
|
||||
---
|
||||
|
||||
Add `gitlabDiscoveryEntityProviderCatalogModule` (new backend-plugin-api, alpha).
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-github-issues': patch
|
||||
---
|
||||
|
||||
Stripping specific issues URL already present to target base issues URL.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-azure': patch
|
||||
---
|
||||
|
||||
`AzureDevOpsEntityProvider`: Add option to configure schedule via `app-config.yaml` instead of in code.
|
||||
|
||||
Please find how to configure the schedule at the config at
|
||||
https://backstage.io/docs/integrations/azure/discovery
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': patch
|
||||
---
|
||||
|
||||
Bumped create-app version.
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
'@backstage/plugin-github-pull-requests-board': patch
|
||||
---
|
||||
|
||||
Replace the momentjs dependency with luxon.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-msgraph': patch
|
||||
---
|
||||
|
||||
`MicrosoftGraphOrgEntityProvider`: Add option to configure schedule via `app-config.yaml` instead of in code.
|
||||
|
||||
Please find how to configure the schedule at the config at
|
||||
https://github.com/backstage/backstage/tree/master/plugins/catalog-backend-module-msgraph#readme
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
'@backstage/plugin-techdocs': minor
|
||||
---
|
||||
|
||||
Add ability to configure filters when using EntityListDocsGrid
|
||||
|
||||
The following example will render two sections of cards grid:
|
||||
|
||||
- One section for documentations tagged as `recommended`
|
||||
- One section for documentations tagged as `runbook`
|
||||
|
||||
```js
|
||||
<EntityListDocsGrid groups={{[
|
||||
{
|
||||
title: "Recommended Documentation",
|
||||
filterPredicate: entity =>
|
||||
entity?.metadata?.tags?.includes('recommended') ?? false,
|
||||
},
|
||||
{
|
||||
title: "RunBooks Documentation",
|
||||
filterPredicate: entity =>
|
||||
entity?.metadata?.tags?.includes('runbook') ?? false,
|
||||
}
|
||||
]}} />
|
||||
```
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-github': minor
|
||||
---
|
||||
|
||||
BREAKING: Support authenticated backends by including a server token for catalog requests. The constructor of `GithubLocationAnalyzer` now requires an instance of `TokenManager` to be supplied:
|
||||
|
||||
```diff
|
||||
...
|
||||
builder.addLocationAnalyzers(
|
||||
new GitHubLocationAnalyzer({
|
||||
discovery: env.discovery,
|
||||
config: env.config,
|
||||
+ tokenManager: env.tokenManager,
|
||||
}),
|
||||
);
|
||||
...
|
||||
```
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-plugin-api': minor
|
||||
---
|
||||
|
||||
The app `Router` component now accepts an optional `basename` property.
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
'@backstage/plugin-techdocs-node': patch
|
||||
'@backstage/plugin-techdocs-backend': patch
|
||||
---
|
||||
|
||||
Replace usage of deprecataed `UrlReader.read` with `UrlReader.readUrl`.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': minor
|
||||
---
|
||||
|
||||
Added a set of default Prometheus metrics around scaffolding. See below for a list of metrics and an explanation of their labels:
|
||||
|
||||
- `scaffolder_task_count`: Tracks successful task runs.
|
||||
|
||||
Labels:
|
||||
|
||||
- `template`: The entity ref of the scaffolded template
|
||||
- `user`: The entity ref of the user that invoked the template run
|
||||
- `result`: A string describing whether the task ran successfully, failed, or was skipped
|
||||
|
||||
- `scaffolder_task_duration`: a histogram which tracks the duration of a task run
|
||||
|
||||
Labels:
|
||||
|
||||
- `template`: The entity ref of the scaffolded template
|
||||
- `result`: A boolean describing whether the task ran successfully
|
||||
|
||||
- `scaffolder_step_count`: a count that tracks each step run
|
||||
|
||||
Labels:
|
||||
|
||||
- `template`: The entity ref of the scaffolded template
|
||||
- `step`: The name of the step that was run
|
||||
- `result`: A string describing whether the task ran successfully, failed, or was skipped
|
||||
|
||||
- `scaffolder_step_duration`: a histogram which tracks the duration of each step run
|
||||
|
||||
Labels:
|
||||
|
||||
- `template`: The entity ref of the scaffolded template
|
||||
- `step`: The name of the step that was run
|
||||
- `result`: A string describing whether the task ran successfully, failed, or was skipped
|
||||
|
||||
You can find a guide for running Prometheus metrics here: https://github.com/backstage/backstage/blob/master/contrib/docs/tutorials/prometheus-metrics.md
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-gitlab': patch
|
||||
---
|
||||
|
||||
`GitlabDiscoveryEntityProvider`: Add option to configure schedule via `app-config.yaml` instead of in code.
|
||||
|
||||
Please find how to configure the schedule at the config at
|
||||
https://backstage.io/docs/integrations/gitlab/discovery
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-common': patch
|
||||
---
|
||||
|
||||
Generated development HTTPS backend certificate is now checked for expiration date instead of file age.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-openapi': patch
|
||||
---
|
||||
|
||||
Added support to use the `UrlReaders` when `$ref` pointing to a URL.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/integration': minor
|
||||
---
|
||||
|
||||
This patch brings Gitea as a valid integration: target, via the ScmIntegration interface. It adds gitea to the relevant static properties (get integration by name, get integration by type) for plugins to be able to reference the same Gitea server.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-common': patch
|
||||
---
|
||||
|
||||
This patch adds GiteaURLReader to the available classes. It currently only reads single files via gitea's public repos api
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
'@backstage/plugin-auth-backend': patch
|
||||
'@backstage/plugin-cost-insights': patch
|
||||
'@backstage/plugin-dynatrace': patch
|
||||
'@backstage/plugin-stack-overflow-backend': patch
|
||||
'@backstage/plugin-techdocs': patch
|
||||
---
|
||||
|
||||
Tweak README
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-aws': patch
|
||||
---
|
||||
|
||||
`AwsS3EntityProvider`: Add option to configure schedule via `app-config.yaml` instead of in code.
|
||||
|
||||
Please find how to configure the schedule at the config at
|
||||
https://backstage.io/docs/integrations/aws-s3/discovery
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
'@backstage/integration': minor
|
||||
---
|
||||
|
||||
Replaces in-code uses of `GitHub` with `Github` and deprecates old versions.
|
||||
|
||||
Deprecates:
|
||||
|
||||
- `getGitHubFileFetchUrl` replaced by `getGithubFileFetchUrl`
|
||||
- `GitHubIntegrationConfig` replaced by `GithubIntegrationConfig`
|
||||
- `GitHubIntegration` replaced by `GithubIntegration`
|
||||
- `readGitHubIntegrationConfig` replaced by `readGithubIntegrationConfig`
|
||||
- `readGitHubIntegrationConfigs` replaced by `readGithubIntegrationConfigs`
|
||||
- `replaceGitHubUrlType` replaced by `replaceGithubUrlType`
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
'@backstage/cli': minor
|
||||
---
|
||||
|
||||
Added a new ESLint rule that restricts imports of Link from @material-ui
|
||||
|
||||
The rule can be can be overridden in the following way:
|
||||
|
||||
```diff
|
||||
module.exports = require('@backstage/cli/config/eslint-factory')(__dirname, {
|
||||
+ restrictedImports: [
|
||||
+ { name: '@material-ui/core', importNames: [] },
|
||||
+ { name: '@material-ui/core/Link', importNames: [] },
|
||||
+ ],
|
||||
});
|
||||
```
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': minor
|
||||
---
|
||||
|
||||
- The GitLab Project ID for the `publish:gitlab:merge-request` action is now passed through the query parameter `project` in the `repoUrl`. It still allows people to not use the `projectid` and use the `repoUrl` with the `owner` and `repo` query parameters instead. This makes it easier to publish to repositories instead of writing the full path to the project.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-import': patch
|
||||
---
|
||||
|
||||
Get rid of `this-is-undefined-in-esm` warning
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-react': patch
|
||||
---
|
||||
|
||||
Removed forced capitalization for Entity types in the catalog sidebar.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-app-api': minor
|
||||
---
|
||||
|
||||
Deprecated the `homepage` config as the component that used it - `HomepageTimer` - has been removed and replaced by the `HeaderWorldClock` in the home plugin
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-azure': patch
|
||||
---
|
||||
|
||||
Add `azureDevOpsEntityProviderCatalogModule` (new backend-plugin-api, alpha).
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-aws': patch
|
||||
---
|
||||
|
||||
Add `awsS3EntityProviderCatalogModule` (new backend-plugin-api, alpha).
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-tasks': patch
|
||||
---
|
||||
|
||||
Deprecated the `HumanDuration` type, which should now instead be imported from `@backstage/types`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-tech-radar': patch
|
||||
---
|
||||
|
||||
Fixed bug in Tech Radar where, on hover, the tech list quadrant would rerender and scroll top
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-common': patch
|
||||
---
|
||||
|
||||
Small update to fix compatibility with newer versions of the `keyv` library
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
'@backstage/plugin-playlist': patch
|
||||
'@backstage/plugin-playlist-backend': patch
|
||||
---
|
||||
|
||||
Updated Playlist plugin docs:
|
||||
|
||||
- Updated `playlist` plugin README to include note about installing backend plugin and added images for the various features
|
||||
- Updated `playlist-backend` plugin README to remove `IdentityClient` import in example as it is not used and made minor change to headings
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Updated `@swc/core` to version 1.3.9 which fixes a `.tsx` parser bug
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-msgraph': patch
|
||||
---
|
||||
|
||||
Add `microsoftGraphOrgEntityProviderCatalogModule` (new backend-plugin-api, alpha).
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-gerrit': patch
|
||||
---
|
||||
|
||||
Add `gerritEntityProviderCatalogModule` (new backend-plugin-api, alpha).
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-azure-devops-backend': patch
|
||||
---
|
||||
|
||||
- Adjusted the asset parser to accept case sensitive
|
||||
- Fixed fetching data that was using the deprecated function
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-github-pull-requests-board': patch
|
||||
---
|
||||
|
||||
Add a new "Team" Filter Options to the Github Pull Requests Dashboard.
|
||||
|
||||
When toggling this option on, the dashboard will displays all of the PRs opened
|
||||
by the members of that team on any repositories of the organization.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
'@backstage/catalog-model': patch
|
||||
'@backstage/core-components': patch
|
||||
'@backstage/integration': patch
|
||||
'@backstage/plugin-auth-node': patch
|
||||
'@backstage/plugin-gcalendar': patch
|
||||
'@backstage/plugin-periskop': patch
|
||||
'@backstage/plugin-permission-common': patch
|
||||
'@backstage/plugin-scaffolder-backend': patch
|
||||
'@backstage/plugin-techdocs': patch
|
||||
'@backstage/plugin-xcmetrics': patch
|
||||
---
|
||||
|
||||
Internal refactor of imports to avoid circular dependencies
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-github': patch
|
||||
---
|
||||
|
||||
Properly derive Github credentials when making requests in `GithubLocationAnalyzer` to support Github App authentication
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-ilert': minor
|
||||
---
|
||||
|
||||
Added support for multiple responders in alert list, added new tab with list to support iLert resource 'service', added new tab with list to support iLert resource 'status page'
|
||||
+75
-2
@@ -173,7 +173,80 @@
|
||||
"@backstage/plugin-user-settings-backend": "0.1.1",
|
||||
"@backstage/plugin-vault": "0.1.4",
|
||||
"@backstage/plugin-vault-backend": "0.2.3",
|
||||
"@backstage/plugin-xcmetrics": "0.2.30"
|
||||
"@backstage/plugin-xcmetrics": "0.2.30",
|
||||
"@backstage/plugin-azure-sites": "0.0.0",
|
||||
"@backstage/plugin-azure-sites-backend": "0.0.0",
|
||||
"@backstage/plugin-azure-sites-common": "0.0.0"
|
||||
},
|
||||
"changesets": []
|
||||
"changesets": [
|
||||
"analyze-software-creation",
|
||||
"analyze-software-exploration",
|
||||
"beige-gorillas-sip",
|
||||
"big-islands-add",
|
||||
"brave-eels-allow",
|
||||
"brown-days-pretend",
|
||||
"calm-bottles-happen",
|
||||
"chatty-planets-flash",
|
||||
"clean-feet-remain",
|
||||
"clean-planets-rhyme",
|
||||
"create-app-1667233110",
|
||||
"dirty-birds-burn",
|
||||
"dull-oranges-tap",
|
||||
"eight-pears-attack",
|
||||
"eleven-pets-sneeze",
|
||||
"few-books-remember",
|
||||
"flat-items-perform",
|
||||
"flat-kangaroos-kiss",
|
||||
"forty-bags-trade",
|
||||
"forty-jokes-lie",
|
||||
"fresh-cooks-sing",
|
||||
"fresh-weeks-share",
|
||||
"gorgeous-balloons-sit",
|
||||
"gorgeous-onions-thank",
|
||||
"gorgeous-queens-pull",
|
||||
"great-colts-invite",
|
||||
"grumpy-clouds-drum",
|
||||
"grumpy-pigs-reflect",
|
||||
"happy-avocados-tan",
|
||||
"heavy-elephants-nail",
|
||||
"itchy-paws-protect",
|
||||
"kind-emus-juggle",
|
||||
"lazy-planes-repair",
|
||||
"little-bikes-eat",
|
||||
"lucky-cats-peel",
|
||||
"lucky-cobras-sell",
|
||||
"lucky-spoons-hide",
|
||||
"mean-files-fly",
|
||||
"metal-dogs-swim",
|
||||
"metal-hairs-mix",
|
||||
"nasty-crabs-share",
|
||||
"orange-trees-peel",
|
||||
"popular-bulldogs-lie",
|
||||
"popular-mails-wave",
|
||||
"real-swans-repair",
|
||||
"renovate-6fb5f1b",
|
||||
"selfish-kiwis-matter",
|
||||
"shaggy-birds-happen",
|
||||
"shaggy-colts-watch",
|
||||
"sharp-goats-itch",
|
||||
"shiny-beers-relax",
|
||||
"short-balloons-work",
|
||||
"sixty-islands-develop",
|
||||
"sixty-pigs-shave",
|
||||
"sixty-singers-push",
|
||||
"spicy-parents-lick",
|
||||
"spotty-dryers-explain",
|
||||
"stupid-pens-occur",
|
||||
"sweet-readers-compare",
|
||||
"tame-ads-appear",
|
||||
"tasty-colts-hug",
|
||||
"tasty-scissors-tickle",
|
||||
"ten-pens-draw",
|
||||
"three-houses-agree",
|
||||
"three-poems-think",
|
||||
"two-oranges-joke",
|
||||
"two-yaks-wave",
|
||||
"unlucky-buttons-poke",
|
||||
"wet-cameras-call"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-permission-common': patch
|
||||
---
|
||||
|
||||
Properly handle rules that have no parameters in `PermissionClient`
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Updated dependency `@svgr/plugin-jsx` to `6.5.x`.
|
||||
Updated dependency `@svgr/plugin-svgo` to `6.5.x`.
|
||||
Updated dependency `@svgr/rollup` to `6.5.x`.
|
||||
Updated dependency `@svgr/webpack` to `6.5.x`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': patch
|
||||
---
|
||||
|
||||
Updated `@swc/core` to `v1.3.9` which fixes a `.tsx` parser bug. You may want to run `yarn backstage-cli versions:bump` to get on latest version including the CLI itself.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-github-issues': minor
|
||||
---
|
||||
|
||||
**BREAKING**: Changed the casing of all exported types to have a lowercase "h" in "github". E.g. "GitHubIssuesPage" was renamed to "GithubIssuesPage". Please rename your imports where necessary.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
Disable base path workaround in `Link` component when React Router v6 stable is used.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/types': patch
|
||||
---
|
||||
|
||||
Added the `HumanDuration` type, moved here from `@backstage/backend-tasks`. This type matches the `Duration.fromObject` form of `luxon`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': patch
|
||||
---
|
||||
|
||||
Updated the create-app command to no longer require Git to be installed and configured. A git repository will only be initialized if possible and if not already in an git repository.
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
'@backstage/plugin-bitrise': patch
|
||||
'@backstage/plugin-code-coverage': patch
|
||||
'@backstage/plugin-cost-insights': minor
|
||||
'@backstage/plugin-git-release-manager': patch
|
||||
'@backstage/plugin-xcmetrics': patch
|
||||
---
|
||||
|
||||
Updated recharts to v2.0.0 and fixed typing issues
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder': minor
|
||||
---
|
||||
|
||||
Added props to override default Scaffolder page title, subtitle and pageTitleOverride.
|
||||
Routes like `rootRouteRef`, `selectedTemplateRouteRef`, `nextRouteRef`, `nextSelectedTemplateRouteRef` were made public and can be used in your app (e.g. in custom TemplateCard component).
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
'@backstage/backend-common': patch
|
||||
'@backstage/plugin-catalog-backend-module-github': patch
|
||||
'@backstage/plugin-catalog-import': patch
|
||||
'@backstage/plugin-git-release-manager': patch
|
||||
'@backstage/plugin-github-actions': patch
|
||||
'@backstage/plugin-github-issues': patch
|
||||
'@backstage/plugin-github-pull-requests-board': patch
|
||||
'@backstage/plugin-techdocs': patch
|
||||
'@backstage/plugin-techdocs-module-addons-contrib': patch
|
||||
---
|
||||
|
||||
Replaces in-code uses of `GitHub` with `Github` and deprecates old versions.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-bazaar': minor
|
||||
---
|
||||
|
||||
The limit prop of BazaarOverviewCard has been removed entirely, and instead replaced with a new optional boolean prop `fullWidth`. The BazaarOverviewCard now always use full height without fixed width. Also fixed problem with link to Bazaar.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-techdocs': patch
|
||||
---
|
||||
|
||||
Include query parameters when navigating to relative links in documents
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-xcmetrics': patch
|
||||
---
|
||||
|
||||
Removed an unused and hidden build details route.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': minor
|
||||
---
|
||||
|
||||
**BREAKING**: Removed the `HomepageTimer` as it has been replaced by the `HeaderWorldClock` in the Home plugin and was deprecated over a year ago.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-circleci': patch
|
||||
---
|
||||
|
||||
Update screenshots in documentation to match latest CircleCI plugin
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-tech-insights-backend': patch
|
||||
'@backstage/plugin-tech-insights-node': patch
|
||||
---
|
||||
|
||||
Add a default delay to the fact retrievers to prevent cold-start errors
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/plugin-azure-sites': minor
|
||||
'@backstage/plugin-azure-sites-backend': minor
|
||||
'@backstage/plugin-azure-sites-common': minor
|
||||
---
|
||||
|
||||
Azure Sites (Apps & Functions) support for a given entity. View the current status of the site, quickly jump to site's Overview page, or Log Stream page.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-bitbucket-server': patch
|
||||
---
|
||||
|
||||
`BitbucketServerEntityProvider`: Add option to configure schedule via `app-config.yaml` instead of in code.
|
||||
|
||||
Please find how to configure the schedule at the config at
|
||||
https://backstage.io/docs/integrations/bitbucketServer/discovery
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-gerrit': patch
|
||||
---
|
||||
|
||||
`GerritEntityProvider`: Add option to configure schedule via `app-config.yaml` instead of in code.
|
||||
|
||||
Please find how to configure the schedule at the config at
|
||||
https://backstage.io/docs/integrations/gerrit/discovery
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-tech-insights-backend': patch
|
||||
'@backstage/plugin-tech-insights-node': patch
|
||||
---
|
||||
|
||||
Use `HumanDuration` from `@backstage/types`
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-github': minor
|
||||
---
|
||||
|
||||
Added the ability for the GitHub discovery provider to validate that catalog files exist before emitting them.
|
||||
|
||||
Users can now set the `validateLocationsExist` property to `true` in their GitHub discovery configuration to opt in to this feature.
|
||||
This feature only works with `catalogPath`s that do not contain wildcards.
|
||||
|
||||
When `validateLocationsExist` is set to `true`, the GitHub discovery provider will retrieve the object from the
|
||||
repository at the provided `catalogPath`.
|
||||
If this file exists and is non-empty, then it will be emitted as a location for further processing.
|
||||
If this file does not exist or is empty, then it will not be emitted.
|
||||
Not emitting locations that do not exist allows for far fewer calls to the GitHub API to validate locations that do not exist.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-bitbucket-server': patch
|
||||
---
|
||||
|
||||
Add `bitbucketServerEntityProviderCatalogModule` (new backend-plugin-api, alpha).
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
'@backstage/create-app': patch
|
||||
'@backstage/plugin-azure-sites': patch
|
||||
'@backstage/plugin-catalog': patch
|
||||
'@backstage/plugin-circleci': patch
|
||||
'@backstage/plugin-cloudbuild': patch
|
||||
'@backstage/plugin-dynatrace': patch
|
||||
'@backstage/plugin-gcalendar': patch
|
||||
'@backstage/plugin-github-actions': patch
|
||||
'@backstage/plugin-github-issues': patch
|
||||
'@backstage/plugin-gitops-profiles': patch
|
||||
'@backstage/plugin-jenkins': patch
|
||||
'@backstage/plugin-kafka': patch
|
||||
'@backstage/plugin-pagerduty': patch
|
||||
'@backstage/plugin-rollbar': patch
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
---
|
||||
|
||||
Prefer using `Link` from `@backstage/core-components` rather than material-UI.
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
'@backstage/integration': patch
|
||||
'@backstage/plugin-catalog-backend-module-aws': patch
|
||||
'@backstage/plugin-catalog-backend-module-gerrit': patch
|
||||
'@backstage/plugin-stack-overflow-backend': patch
|
||||
'@backstage/plugin-techdocs-backend': patch
|
||||
---
|
||||
|
||||
Remove explicit default visibility at `config.d.ts` files.
|
||||
|
||||
```ts
|
||||
/**
|
||||
* @visibility backend
|
||||
*/
|
||||
```
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
'@backstage/plugin-kubernetes-backend': minor
|
||||
'@backstage/plugin-kubernetes-common': patch
|
||||
---
|
||||
|
||||
The Kubernetes errors when fetching pod metrics are now captured and returned to the frontend.
|
||||
|
||||
- **BREAKING** The method `fetchPodMetricsByNamespace` in the interface `KubernetesFetcher` is changed to `fetchPodMetricsByNamespaces`. It now accepts a set of namespace strings and returns `Promise<FetchResponseWrapper>`.
|
||||
- Add the `PodStatusFetchResponse` to the `FetchResponse` union type.
|
||||
- Add `NOT_FOUND` to the `KubernetesErrorTypes` union type, the HTTP error with status code 404 will be mapped to this error.
|
||||
@@ -0,0 +1,84 @@
|
||||
name: '🐛 Bug Report'
|
||||
description: 'Submit a bug report to help us improve'
|
||||
title: '🐛 Bug Report: '
|
||||
labels:
|
||||
- bug
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: We value your time and effort to submit this bug report. 🙏
|
||||
- type: textarea
|
||||
id: description
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '📜 Description'
|
||||
description: 'A clear and concise description of what the bug is.'
|
||||
placeholder: 'It bugs out when ...'
|
||||
- type: textarea
|
||||
id: expected-behavior
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '👍 Expected behavior'
|
||||
description: 'What did you think should happen?'
|
||||
placeholder: 'It should ...'
|
||||
- type: textarea
|
||||
id: actual-behavior
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '👎 Actual Behavior with Screenshots'
|
||||
description: 'What did actually happen? Add screenshots, if applicable.'
|
||||
placeholder: 'It actually ...'
|
||||
- type: textarea
|
||||
id: steps-to-reproduce
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '👟 Reproduction steps'
|
||||
description: 'How do you trigger this bug? Please walk us through it step by step.'
|
||||
placeholder:
|
||||
"Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include code or configuration to reproduce, if relevant.\n
|
||||
1. Go to '...'\n
|
||||
2. Click on '....'\n
|
||||
3. Scroll down to '....'"
|
||||
- type: textarea
|
||||
id: context
|
||||
validations:
|
||||
required: false
|
||||
attributes:
|
||||
label: '📃 Provide the context for the Bug.'
|
||||
description: 'How has this issue affected you? What are you trying to accomplish?'
|
||||
placeholder: 'Providing context (e.g. links to configuration settings, stack trace or log data) helps us come up with a solution that is most useful in the real world.'
|
||||
- type: textarea
|
||||
id: environment
|
||||
validations:
|
||||
required: false
|
||||
attributes:
|
||||
label: '🖥️ Your Environment'
|
||||
description: 'Provide Browser Information
|
||||
Provide Output of `yarn backstage-cli info`'
|
||||
placeholder: 'Include as many relevant details about the environment you experienced the bug in.'
|
||||
- type: checkboxes
|
||||
id: no-duplicate-issues
|
||||
attributes:
|
||||
label: '👀 Have you spent some time to check if this bug has been raised before?'
|
||||
options:
|
||||
- label: "I checked and didn't find similar issue"
|
||||
required: true
|
||||
- type: checkboxes
|
||||
id: read-code-of-conduct
|
||||
attributes:
|
||||
label: '🏢 Have you read the Code of Conduct?'
|
||||
options:
|
||||
- label: 'I have read the [Code of Conduct](https://github.com/backstage/backstage/blob/master/CODE_OF_CONDUCT.md)'
|
||||
required: true
|
||||
- type: dropdown
|
||||
attributes:
|
||||
label: Are you willing to submit PR?
|
||||
description: This is absolutely not required, but we are happy to guide you in the contribution process.
|
||||
options:
|
||||
- Yes I am willing to submit a PR!
|
||||
- No, but I'm happy to collaborate on a PR with someone else
|
||||
- No, I don't have time to work on this right now
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
name: 'Bug Report'
|
||||
about: 'Create Bug Report'
|
||||
labels: bug
|
||||
---
|
||||
|
||||
<!---
|
||||
Please use this template when reporting bugs. Thank you!
|
||||
-->
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
<!--- Tell us what should happen -->
|
||||
|
||||
## Actual Behavior
|
||||
|
||||
<!--- Tell us what happens instead -->
|
||||
|
||||
## Steps to Reproduce
|
||||
|
||||
<!--- Provide a link to a live example, or an unambiguous set of steps to -->
|
||||
<!--- reproduce this bug. Include code or configuration to reproduce, if relevant -->
|
||||
|
||||
1. Step 1
|
||||
2. Step 2
|
||||
3. ...
|
||||
|
||||
## Context
|
||||
|
||||
<!--- How has this issue affected you? What are you trying to accomplish? -->
|
||||
<!--- Providing context (e.g. links to configuration settings, -->
|
||||
<!--- stack trace or log data) helps us come up with a solution that is most useful in the real world -->
|
||||
|
||||
## Your Environment
|
||||
|
||||
<!--- Include as many relevant details about the environment you experienced the bug in -->
|
||||
|
||||
- Browser Information: <!--- For example Google Chrome 97.0.4692.99 -->
|
||||
|
||||
- Output of `yarn backstage-cli info`: <!--- Paste into the code block below -->
|
||||
|
||||
```text
|
||||
|
||||
```
|
||||
@@ -0,0 +1,54 @@
|
||||
name: 🚀 Feature
|
||||
description: 'Submit a proposal for a new feature'
|
||||
title: '🚀 Feature: '
|
||||
labels: [enhancement]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
We value your time and efforts to submit this Feature request form. 🙏
|
||||
- type: textarea
|
||||
id: feature-description
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '🔖 Feature description'
|
||||
description: 'A clear and concise description of what the feature is.'
|
||||
placeholder: 'You should add ...'
|
||||
- type: textarea
|
||||
id: context
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '🎤 Context'
|
||||
description: 'Please explain why this feature should be implemented and how it would be used. Add examples, if applicable.'
|
||||
placeholder: 'In my use-case, ...'
|
||||
- type: textarea
|
||||
id: implementation
|
||||
attributes:
|
||||
label: '✌️ Possible Implementation'
|
||||
description: 'A clear and concise description of what you want to happen.'
|
||||
placeholder: 'Not obligatory, but ideas as to the implementation of the addition or change'
|
||||
- type: checkboxes
|
||||
id: no-duplicate-issues
|
||||
attributes:
|
||||
label: '👀 Have you spent some time to check if this feature request has been raised before?'
|
||||
options:
|
||||
- label: "I checked and didn't find similar issue"
|
||||
required: true
|
||||
- type: checkboxes
|
||||
id: read-code-of-conduct
|
||||
attributes:
|
||||
label: '🏢 Have you read the Code of Conduct?'
|
||||
options:
|
||||
- label: 'I have read the [Contributing Guidelines](https://github.com/backstage/backstage/blob/master/CODE_OF_CONDUCT.md)'
|
||||
required: true
|
||||
- type: dropdown
|
||||
id: willing-to-submit-pr
|
||||
attributes:
|
||||
label: Are you willing to submit PR?
|
||||
description: This is absolutely not required, but we are happy to guide you in the contribution process.
|
||||
options:
|
||||
- Yes I am willing to submit a PR!
|
||||
- No, but I'm happy to collaborate on a PR with someone else
|
||||
- No, I don't have time to work on this right now
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
name: 'Feature Request'
|
||||
about: 'Suggest new features and changes'
|
||||
labels: enhancement
|
||||
---
|
||||
|
||||
<!--- Provide a general summary of the feature request in the Title above -->
|
||||
|
||||
## Feature Suggestion
|
||||
|
||||
<!--- If you're looking for help, please see https://backstage.io/ --->
|
||||
<!--- Tell us how we could improve your experience -->
|
||||
|
||||
## Possible Implementation
|
||||
|
||||
<!--- Not obligatory, but ideas as to the implementation of the addition or change -->
|
||||
|
||||
## Context
|
||||
|
||||
<!--- What are you trying to accomplish? -->
|
||||
<!--- Providing context (e.g. links to configuration settings, stack trace or log data) -->
|
||||
<!--- helps us come up with a solution that is most useful in the real world -->
|
||||
@@ -0,0 +1,52 @@
|
||||
name: 🔌 Plugin
|
||||
description: 'Submit a proposal for a new Plugin'
|
||||
title: '🔌 Plugin: '
|
||||
labels: [plugin]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
We value your time and efforts to submit this Plugin request form. 🙏
|
||||
- type: textarea
|
||||
id: plugin-summary
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '🔖 Summary'
|
||||
description: 'Provide a general summary of the plugin and how it should work'
|
||||
placeholder: 'You should add ...'
|
||||
- type: textarea
|
||||
id: website
|
||||
attributes:
|
||||
label: '🌐 Project website (if applicable)'
|
||||
description: 'Add a link to the open source project or product this plugin will integrate with, if existing'
|
||||
placeholder: 'Website Link is ...'
|
||||
- type: textarea
|
||||
id: context
|
||||
attributes:
|
||||
label: '✌️ Context'
|
||||
description: 'A clear and concise description about the Plugin.'
|
||||
placeholder: 'Providing additional context'
|
||||
- type: checkboxes
|
||||
id: no-duplicate-issues
|
||||
attributes:
|
||||
label: '👀 Have you spent some time to check if this plugin request has been raised before?'
|
||||
options:
|
||||
- label: "I checked and didn't find similar issue"
|
||||
required: true
|
||||
- type: checkboxes
|
||||
id: read-code-of-conduct
|
||||
attributes:
|
||||
label: '🏢 Have you read the Code of Conduct?'
|
||||
options:
|
||||
- label: 'I have read the [Contributing Guidelines](https://github.com/backstage/backstage/blob/master/CODE_OF_CONDUCT.md)'
|
||||
required: true
|
||||
- type: dropdown
|
||||
id: willing-to-submit-pr
|
||||
attributes:
|
||||
label: Are you willing to submit PR?
|
||||
description: This is absolutely not required, but we are happy to guide you in the contribution process.
|
||||
options:
|
||||
- Yes I am willing to submit a PR!
|
||||
- No, but I'm happy to collaborate on a PR with someone else
|
||||
- No, I don't have time to work on this right now
|
||||
@@ -1,21 +0,0 @@
|
||||
---
|
||||
name: 'Plugin suggestion'
|
||||
about: 'Suggest a new Backstage plugin'
|
||||
title: '[Plugin] THE PLUGIN NAME'
|
||||
labels: plugin
|
||||
---
|
||||
|
||||
<!--- Thanks for suggesting a new plugin! -->
|
||||
<!--- If you plan to work on this plugin, please Assign yourself or your team member(s) -->
|
||||
|
||||
## Summary
|
||||
|
||||
<!--- Provide a general summary of the plugin and how it should work -->
|
||||
|
||||
## Project website (if applicable)
|
||||
|
||||
<!--- Add a link to the open source project or product this plugin will integrate with, if existing -->
|
||||
|
||||
## Context
|
||||
|
||||
<!--- Providing additional context -->
|
||||
@@ -0,0 +1,51 @@
|
||||
name: 💬 RFC
|
||||
description: 'Request For Comments (RFC) from the community'
|
||||
title: '💬 RFC: '
|
||||
labels: [rfc]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
We value your time and efforts to submit this RFC form. 🙏
|
||||
- type: textarea
|
||||
id: rfc-need
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '🔖 Need'
|
||||
description: 'Let us know why are you proposing this change'
|
||||
placeholder: 'The problem we’re trying to address and the benefits/impact we expect to get from this are ...'
|
||||
- type: textarea
|
||||
id: proposal
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '🎉 Proposal'
|
||||
description: 'Describe the proposal in as much detail as needed for reviewers to give concrete feedback.'
|
||||
placeholder: 'Take special care in this section to describe any implications on data privacy or security.'
|
||||
- type: textarea
|
||||
id: alternatives
|
||||
attributes:
|
||||
label: '〽️ Alternatives'
|
||||
description: 'What alternatives to the proposed solution were considered?'
|
||||
placeholder: 'What criteria/data was used to discard these?'
|
||||
- type: textarea
|
||||
id: risk
|
||||
attributes:
|
||||
label: '❌ Risks'
|
||||
description: 'What other things happening could conflict or compete (for example for resources) with the proposal?'
|
||||
placeholder: 'What risk are there and how do we plan to handle them?'
|
||||
- type: checkboxes
|
||||
id: no-duplicate-issues
|
||||
attributes:
|
||||
label: '👀 Have you spent some time to check if this RFC has been raised before?'
|
||||
options:
|
||||
- label: "I checked and didn't find similar issue"
|
||||
required: true
|
||||
- type: checkboxes
|
||||
id: read-code-of-conduct
|
||||
attributes:
|
||||
label: '🏢 Have you read the Code of Conduct?'
|
||||
options:
|
||||
- label: 'I have read the [Code of Conduct](https://github.com/backstage/backstage/blob/master/CODE_OF_CONDUCT.md)'
|
||||
required: true
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
name: 'RFC'
|
||||
about: 'Request For Comments (RFC) from the community'
|
||||
labels: rfc
|
||||
title: '[RFC] <name>'
|
||||
---
|
||||
|
||||
**Status:** Open for comments
|
||||
|
||||
<!--- Open for comments |Closed for comments (RFC no longer maintained) --->
|
||||
|
||||
## Need
|
||||
|
||||
<!--- Why are we proposing this change? Why is this the problem we’re trying to address and what benefits/impact do we expect to get from this --->
|
||||
|
||||
## Proposal
|
||||
|
||||
<!--- The proposed approach. Describe the proposal in as much detail as needed for reviewers to give concrete feedback. Take special care in this section to describe any implications on data privacy or security. --->
|
||||
|
||||
## Alternatives
|
||||
|
||||
<!--- What alternatives to the proposed solution were considered? What criteria/data was used to discard these --->
|
||||
|
||||
## Risks
|
||||
|
||||
<!--- What other things happening could conflict or compete (for example for resources) with the proposal? What risk are there and how do we plan to handle them --->
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
name: 'UX Component'
|
||||
about: 'For designers to request UX components to be added to the Backstage Storybook'
|
||||
labels: design
|
||||
---
|
||||
|
||||
## 🗒 General
|
||||
|
||||
<!--- Write a nice note to the community requesting the creation of a new component! -->
|
||||
<!--- Include an image of your component. Bonus points for a GIF! -->
|
||||
|
||||
## 💻 Usage
|
||||
|
||||
<!--- Tell us what the point of this component/pattern is! How does it help? How should it work? Any rules? -->
|
||||
|
||||
## 📐 Specs
|
||||
|
||||
<!--- Include images that detail the redlines for your component.-->
|
||||
<!--- Once we get our Figma workspace set up, we'll be posting the Figma files rather than doing specs by hand.-->
|
||||
|
||||
## 🔮 Future
|
||||
|
||||
<!-- Any upcoming, exciting functionality for this component in the future? List that out here. -->
|
||||
@@ -0,0 +1,53 @@
|
||||
name: 🦄 UX Component
|
||||
description: 'For designers to request UX components to be added to the Backstage Storybook'
|
||||
title: '🦄 UX Component: '
|
||||
labels: [design]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
We value your time and efforts to submit this RFC form. 🙏
|
||||
- type: textarea
|
||||
id: ux-general
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '🔖 General'
|
||||
description: 'Write a nice note to the community requesting the creation of a new component.'
|
||||
placeholder: 'Include an image of your component. Bonus points for a GIF!'
|
||||
- type: textarea
|
||||
id: usage
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '💻 Usage'
|
||||
description: "Tell us what's the point of this component/pattern is."
|
||||
placeholder: 'How does it help? How should it work? Any rules?'
|
||||
- type: textarea
|
||||
id: specs
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '📐 Specs'
|
||||
description: 'Include images that detail the redlines for your component.'
|
||||
placeholder: "Once we get our Figma workspace set up, we'll be posting the Figma files rather than doing specs by hand."
|
||||
- type: textarea
|
||||
id: future
|
||||
attributes:
|
||||
label: '🔮 Future'
|
||||
description: 'List out any upcoming, exciting functionality for this component.'
|
||||
placeholder: 'The component will have ...'
|
||||
- type: checkboxes
|
||||
id: no-duplicate-issues
|
||||
attributes:
|
||||
label: '👀 Have you spent some time to check if this UX Component request has been raised before?'
|
||||
options:
|
||||
- label: "I checked and didn't find similar issue"
|
||||
required: true
|
||||
- type: checkboxes
|
||||
id: read-code-of-conduct
|
||||
attributes:
|
||||
label: '🏢 Have you read the Code of Conduct?'
|
||||
options:
|
||||
- label: 'I have read the [Code of Conduct](https://github.com/backstage/backstage/blob/master/CODE_OF_CONDUCT.md)'
|
||||
required: true
|
||||
@@ -15,5 +15,10 @@
|
||||
groupName: 'API Extractor / Rush Stack monorepo packages',
|
||||
rangeStrategy: 'replace',
|
||||
},
|
||||
{
|
||||
matchSourceUrlPrefixes: ['https://github.com/gregberge/svgr'],
|
||||
groupName: 'SVGR monorepo packages',
|
||||
rangeStrategy: 'replace',
|
||||
},
|
||||
],
|
||||
}
|
||||
|
||||
@@ -1,11 +1,14 @@
|
||||
abc
|
||||
accessors
|
||||
ACLs
|
||||
addon
|
||||
addons
|
||||
ADRs
|
||||
airbrake
|
||||
Airbrake
|
||||
Airbrakes
|
||||
airbrake
|
||||
Alaria
|
||||
Alef
|
||||
Anddddd
|
||||
Apdex
|
||||
api
|
||||
@@ -17,6 +20,7 @@ autoscaling
|
||||
Autoscaling
|
||||
autoselect
|
||||
Avro
|
||||
backend's
|
||||
backported
|
||||
backporting
|
||||
Bigtable
|
||||
@@ -24,9 +28,9 @@ Billett
|
||||
bitbucket
|
||||
Bitrise
|
||||
Blackbox
|
||||
Brex
|
||||
bool
|
||||
boolean
|
||||
Brex
|
||||
builtins
|
||||
callout
|
||||
CDNs
|
||||
@@ -40,6 +44,7 @@ CI/CD
|
||||
classname
|
||||
cli
|
||||
cloudbuild
|
||||
Cloudflare
|
||||
Cloudformation
|
||||
cncf
|
||||
Cobertura
|
||||
@@ -47,11 +52,11 @@ codeblocks
|
||||
Codecov
|
||||
codehilite
|
||||
Codehilite
|
||||
codescene
|
||||
CodeScene
|
||||
codemod
|
||||
codemods
|
||||
codeowners
|
||||
codescene
|
||||
CodeScene
|
||||
composability
|
||||
composable
|
||||
config
|
||||
@@ -73,8 +78,8 @@ Debounce
|
||||
debuggability
|
||||
declaratively
|
||||
deduplicated
|
||||
deps
|
||||
dependabot
|
||||
deps
|
||||
destructured
|
||||
destructuring
|
||||
dev
|
||||
@@ -88,14 +93,18 @@ dockerfiles
|
||||
Dockerize
|
||||
dockerode
|
||||
Docusaurus
|
||||
DOMPurify
|
||||
don'ts
|
||||
dynatrace
|
||||
Dynatrace
|
||||
ecco
|
||||
elasticsearch
|
||||
env
|
||||
Env
|
||||
elasticsearch
|
||||
esbuild
|
||||
eslint
|
||||
ESModule
|
||||
ESModules
|
||||
etag
|
||||
Expedia
|
||||
facto
|
||||
@@ -111,6 +120,8 @@ Francesco
|
||||
gerrit
|
||||
Gerrit
|
||||
gitbeaker
|
||||
gitea
|
||||
Gitea
|
||||
github
|
||||
Gitiles
|
||||
gitlab
|
||||
@@ -132,23 +143,26 @@ hotspots
|
||||
http
|
||||
https
|
||||
Iain
|
||||
Iglesias
|
||||
iLert
|
||||
img
|
||||
incentivised
|
||||
Indal
|
||||
indexable
|
||||
inlined
|
||||
inlinehilite
|
||||
integrator's
|
||||
interop
|
||||
JaCoCo
|
||||
JavaScript
|
||||
jenkins
|
||||
Jira
|
||||
JWTs
|
||||
jq
|
||||
js
|
||||
json
|
||||
jsonnet
|
||||
jsx
|
||||
JWTs
|
||||
Kaewkasi
|
||||
Keyv
|
||||
Knex
|
||||
@@ -168,6 +182,7 @@ lunr
|
||||
Luxon
|
||||
magiclink
|
||||
mailto
|
||||
maintainer's
|
||||
maintainership
|
||||
makefile
|
||||
md
|
||||
@@ -222,6 +237,7 @@ orgs
|
||||
pagerduty
|
||||
pageview
|
||||
parallelization
|
||||
parseable
|
||||
Patrik
|
||||
Peloton
|
||||
performant
|
||||
@@ -256,14 +272,13 @@ rebase
|
||||
Recharts
|
||||
Redash
|
||||
replicasets
|
||||
statefulsets
|
||||
repo
|
||||
Repo
|
||||
repos
|
||||
rerender
|
||||
rerenders
|
||||
Reusability
|
||||
reusability
|
||||
Reusability
|
||||
roadmaps
|
||||
rollbar
|
||||
Rollbar
|
||||
@@ -286,9 +301,9 @@ semver
|
||||
serializable
|
||||
Serverless
|
||||
shoutout
|
||||
siloed
|
||||
SIG
|
||||
SIGs
|
||||
siloed
|
||||
Sinon
|
||||
Snyk
|
||||
Sonarqube
|
||||
@@ -301,11 +316,17 @@ Spotify
|
||||
sqlite
|
||||
squidfunk
|
||||
src
|
||||
statefulsets
|
||||
stdout
|
||||
stringify
|
||||
storable
|
||||
stringified
|
||||
stringify
|
||||
subcomponent
|
||||
subcomponents
|
||||
subfolder
|
||||
subfolders
|
||||
subheader
|
||||
subheaders
|
||||
subkey
|
||||
subroutes
|
||||
subtree
|
||||
@@ -313,10 +334,10 @@ superfences
|
||||
Superfences
|
||||
superset
|
||||
supertype
|
||||
storable
|
||||
SVGs
|
||||
talkdesk
|
||||
Talkdesk
|
||||
Tanzu
|
||||
tasklist
|
||||
techdocs
|
||||
Telenor
|
||||
@@ -326,6 +347,7 @@ templater
|
||||
Templater
|
||||
templaters
|
||||
Templaters
|
||||
TFRecord
|
||||
theia
|
||||
thumbsup
|
||||
todo
|
||||
@@ -342,6 +364,7 @@ transpiled
|
||||
transpiler
|
||||
transpilers
|
||||
truthy
|
||||
TSDoc
|
||||
typeahead
|
||||
ui
|
||||
unbreak
|
||||
@@ -356,14 +379,17 @@ upvote
|
||||
URIs
|
||||
URLs
|
||||
utils
|
||||
Valentina
|
||||
validator
|
||||
validators
|
||||
varchar
|
||||
VMware
|
||||
VPCs
|
||||
VSCode
|
||||
Wayfair
|
||||
Weaveworks
|
||||
Webpack
|
||||
widget's
|
||||
winston
|
||||
www
|
||||
WWW
|
||||
@@ -373,7 +399,7 @@ xyz
|
||||
yaml
|
||||
Zalando
|
||||
Zhou
|
||||
zod
|
||||
Zolotusky
|
||||
zoomable
|
||||
zsh
|
||||
Alef
|
||||
Cloudflare
|
||||
|
||||
@@ -22,7 +22,8 @@ jobs:
|
||||
stale-pr-message: >
|
||||
This PR has been automatically marked as stale because it has not had
|
||||
recent activity from the author. It will be closed if no further activity occurs.
|
||||
If you are the author and the PR has been closed, feel free to re-open the PR and continue the contribution!
|
||||
If the PR was closed and you want it re-opened, let us know
|
||||
and we'll re-open the PR so that you can continue the contribution!
|
||||
days-before-pr-stale: 7
|
||||
days-before-pr-close: 5
|
||||
exempt-pr-labels: after-vacations,will-fix
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
name: Sync Snyk GitHub issues
|
||||
on:
|
||||
workflow_dispatch:
|
||||
schedule:
|
||||
- cron: '0 */4 * * *'
|
||||
|
||||
@@ -13,9 +14,6 @@ jobs:
|
||||
matrix:
|
||||
node-version: [14.x]
|
||||
|
||||
env:
|
||||
NODE_OPTIONS: --max-old-space-size=4096
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
@@ -38,9 +36,11 @@ jobs:
|
||||
--org=backstage-dgh
|
||||
--strict-out-of-sync=false
|
||||
--json-file-output=snyk.json
|
||||
--debug
|
||||
json: true
|
||||
env:
|
||||
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
|
||||
NODE_OPTIONS: --max-old-space-size=7168
|
||||
- name: Update Github issues
|
||||
run: yarn ts-node scripts/snyk-github-issue-sync.ts
|
||||
env:
|
||||
|
||||
+5
-3
@@ -6,7 +6,7 @@ _You can do this by using the [Adopter form](https://info.backstage.spotify.com/
|
||||
| Organization | Contact | Description of Use |
|
||||
| --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [Spotify](https://www.spotify.com) | [@leemills83](https://github.com/leemills83) | Main interface towards all of Spotify's infrastructure and technical documentation. |
|
||||
| [bol.com](https://www.bol.com) | [@sagacity](https://github.com/sagacity) | Initial work being done to unify platform tooling. |
|
||||
| [bol.com](https://www.bol.com) | [@acierto](https://github.com/acierto), [@clanghout](https://github.com/clanghout) | Initial work being done to unify platform tooling. |
|
||||
| [DFDS](https://www.dfds.com) | [@carlsendk](https://github.com/carlsendk) | V2 self-service platform. |
|
||||
| [Roadie](https://roadie.io) | [@dtuite](https://github.com/dtuite) | Hosted, managed Backstage with easy set-up |
|
||||
| [Roku](https://www.roku.com) | [@timurista](https://github.com/timurista) | Initial work on Cloud engineering service platform. |
|
||||
@@ -25,7 +25,7 @@ _You can do this by using the [Adopter form](https://info.backstage.spotify.com/
|
||||
| [Expedia Group](https://www.expediagroup.com) | [@gman0922](https://github.com/gman0922), [Sheena Sharma](mailto:shesharma@expediagroup.com), [Alekhya Karuturi](mailto:akaruturi@expediagroup.com) | EG Developer Front Door |
|
||||
| [Paddle.com](https://paddle.com) | [Ioannis Georgoulas](https://github.com/geototti21) | Developer portal (Tech Docs, Service Catalog, Internal Tooling), we use vanilla Backstage FE and custom BE implementation in Go |
|
||||
| [Acast.com](https://acast.com) | [Olle Lundberg](https://github.com/lndbrg) | Developer portal with tech docs, service catalog and a bunch of other internal tooling |
|
||||
| [Lunar](https://lunar.app) | [Jacob Valdemar](https://github.com/JacobValdemar) | Internal developer portal for service overview and insights, API documentation, technical guides, onboarding guides and RFC's. |
|
||||
| [Lunar](https://lunar.app) | [Bjørn Hald Sørensen](https://github.com/crevil) | Internal developer portal for service overview and insights, API documentation, technical guides, onboarding guides and RFC's. |
|
||||
| [Trendyol](https://trendyol.com) | [Gamze Senturk](https://github.com/gmzsenturk), [Mert Can Bilgic](https://github.com/mertcb) | The Developer Portal has been called `Pandora`. Provides an overview of Trendyol tech ecosystem. TechDocs, Catalog, Custom Plugins and Theme. |
|
||||
| [Peloton](https://www.onepeloton.com/) | [Matt Waldron](https://github.com/daftgopher) | Creating our first developer portal and tech-docs. Exploring Service Catalog, Tech Insights and Cost Insights as well. |
|
||||
| [Brex](https://www.brex.com/) | [Vamsi Chitters](https://github.com/vamsikc) | A centralized UI to understand how a service fits in the whole Brex architecture and manage a team’s engineering dependencies. |
|
||||
@@ -214,4 +214,6 @@ _You can do this by using the [Adopter form](https://info.backstage.spotify.com/
|
||||
| [Vipps](https://vipps.no) | [Martin Ehrnst](https://github.com/ehrnst) | Vipps use backstage for our service catalog, documentation, and developer portal. Using templates we are able to simplify the developer experience when deploying new services to our platform. |
|
||||
| [Ferrovial](https://ferrovial.com) | [Jose Luis Rosado](mailto:jlrosado@ferrovial.com) | Backstage is helping us to improve and acelerate dev experience helping teams to quickly find technical documentation, infrastructure templates, pipelines, software components and quickstarters that have been developed by our squads in a inner source friendly environment. |
|
||||
| [Inter&Co](https://bancointer.com.br) | [Arnaud Lanna](https://github.com/arnaudlanna), [Adriano Silva](https://github.com/adrianovss), [Bruno Grossi](https://github.com/begrossi) | We're using Backstage as our internal Developer Portal to catalog and collect repositories and microservices pieces of information like ownership, deployment time, and documentation. |
|
||||
| [StatusNeo](https://statusneo.com/) | [Karan Nangru](mailto:nangru@statusneo.com), [@NishkarshRaj](https://github.com/NishkarshRaj), and [Gaurav Sarien](mailto:gaurav.sarien@statusneo.com) | Harnessing the power of central catalog inventory and self-serving software templates |
|
||||
| [StatusNeo](https://statusneo.com/) | [Karan Nangru](mailto:nangru@statusneo.com), [@NishkarshRaj](https://github.com/NishkarshRaj), and [Gaurav Sarien](mailto:gaurav.sarien@statusneo.com) | Harnessing the power of central catalog inventory and self-serving software templates |
|
||||
| [Alaska Airlines](https://alaskaair.com) | [@swerdick](https://github.com/swerdick) | Backstage is the developer portal for our 'software delivery platform'. Consolidating developer tools to one place, and providing automation to make it easy for developers to create and deploy applications to Kubernetes
|
||||
| [Loft](https://loft.com.br) | [Augusto Hoffmann](mailto:augusto.hoffmann@loft.com.br) | We're using Backstage to give visibility and promote ownership of all our applications, resources and tools. Now moving to use it as a Developer Portal to create applications, AWS resources etc. |
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
[](https://discord.gg/EBHEGzX)
|
||||
|
||||
[](https://codecov.io/gh/backstage/backstage)
|
||||
[](https://github.com/backstage/backstage/releases)
|
||||
[](https://github.com/backstage/backstage/releases)
|
||||
|
||||
## What is Backstage?
|
||||
|
||||
@@ -52,8 +52,8 @@ Check out [the documentation](https://backstage.io/docs/getting-started) on how
|
||||
- [Code of Conduct](CODE_OF_CONDUCT.md) - This is how we roll
|
||||
- [Adopters](ADOPTERS.md) - Companies already using Backstage
|
||||
- [Blog](https://backstage.io/blog/) - Announcements and updates
|
||||
- [Newsletter](https://mailchi.mp/spotify/backstage-community) - Subscribe to our email newsletter
|
||||
- [Backstage Community Sessions](https://github.com/backstage/community) - Join monthly meetup and explore Backstage community
|
||||
- [Newsletter](https://spoti.fi/backstagenewsletter) - Subscribe to our email newsletter
|
||||
- [Backstage Community Sessions](https://github.com/backstage/community) - Join monthly meetups and explore Backstage community
|
||||
- Give us a star ⭐️ - If you are using Backstage or think it is an interesting project, we would love a star ❤️
|
||||
|
||||
## License
|
||||
|
||||
+317
@@ -0,0 +1,317 @@
|
||||
# Introduction
|
||||
|
||||
This file provides pointers for reviewing pull requests. While the main audience are reviewers, this can also be useful if you are contributing to this repository.
|
||||
|
||||
## Code Style
|
||||
|
||||
See our code style documented at [STYLE.md](./STYLE.md).
|
||||
|
||||
In particular when it comes to naming, make sure that naming follows established conventions within the project and/or package.
|
||||
|
||||
When adding new dependencies to packages it is always preferred to use version ranges that are already in use by other packages in the repository. This helps minimize lockfile changes and reduce package duplication, both in our repository as well as other Backstage installations.
|
||||
|
||||
## Secure Coding Practices
|
||||
|
||||
Be sure to familiarize yourself with our [secure coding practices](./SECURITY.md#coding-practices).
|
||||
|
||||
## Release & Versioning Policy
|
||||
|
||||
When reviewing pull requests it's important to consider our [versioning policy and release cycle](https://backstage.io/docs/overview/versioning-policy). Generally the most important bit is our [package versioning policy](https://backstage.io/docs/overview/versioning-policy#package-versioning-policy), which describes when and how we can ship breaking changes. We'll dive into how to identify breaking changes in a different section.
|
||||
|
||||
One other thing to keep in mind, especially when merging pull requests, is where in the release cycle we're currently at. In particular you want to avoid merging any large or risky changes towards the end of each release cycle. If there is a change that is ready to be merged, but you want to hold off until the next main line release, then you can label it with the `merge-after-release` label.
|
||||
|
||||
## Changesets
|
||||
|
||||
We use changesets to track changes in all published packages. Changesets both define what should go into the changelog of each package, but also what kind of version bump should be done for the next release.
|
||||
An introduction to changesets can be found in our [contribution guidelines](./CONTRIBUTING.md#creating-changesets).
|
||||
|
||||
When reviewing a changeset, the most important things to look for are the bump levels, i.e. `major` / `minor` / `patch`, as well as whether the content is accurate and if it's written in a way that makes sense when reading it in the changelog for each package.
|
||||
|
||||
### Reviewing Changeset Bump Levels
|
||||
|
||||
The following table provides a reference for what type of version bump is needed for each package. This is applied separately to each individual package, it does not matter what the scope of a change is in any other broader context.
|
||||
|
||||
| Scope | Current Package Version | Bump Level |
|
||||
| --------------- | ----------------------- | ---------- |
|
||||
| Breaking Change | `1.0` and above | `major` |
|
||||
| New Feature | `1.0` and above | `minor` |
|
||||
| Fix | `1.0` and above | `patch` |
|
||||
| Breaking Change | `0.x` | `minor` |
|
||||
| New Feature | `0.x` | `patch` |
|
||||
| Fix | `0.x` | `patch` |
|
||||
|
||||
The only situation where a package that is currently at `0.x` can have a `major` bump is if all owners and stakeholders of the package agree that the package is ready to be released as `1.0`.
|
||||
|
||||
### Reviewing Changeset Content
|
||||
|
||||
Each changeset should be written in a way that describes the impact of the change for the users of each package. The contents of the changesets will end up in the changelog of each package, for example [@backstage/core-plugin-api](./packages/core-plugin-api/CHANGELOG.md). The changelogs are intended to provide both a summary of the new features as well as guidance in the case of breaking changes or deprecations.
|
||||
|
||||
Some things that changeset should NOT contain are:
|
||||
|
||||
- Internal architecture details - these are generally not interesting to users, focus on the impact towards users of the package instead.
|
||||
- Information related to a different package.
|
||||
- A large amount of content, consider for example a separate migration guide instead, either in the package README or [./docs/](./docs/), and then link to that instead.
|
||||
- Documentation - changesets can describe new features, but it should not be relied on for documenting them. Documentation should either be placed in [TSDoc](https://tsdoc.org) comments, package README, or [./docs/](./docs/).
|
||||
|
||||
### When is a changeset needed?
|
||||
|
||||
In general our changeset feedback bot will take care of informing whether a changeset is needed or not, but there are some edge cases. Whether a changeset is needed depends mostly on what files have been changed, but sometimes also on the kind of change that has been made.
|
||||
|
||||
Changes that do NOT need a new changeset:
|
||||
|
||||
- Changes to any test, storybook, or other local development files, for example, `MyComponent.test.tsx`, `MyComponent.stories.tsx`, `**mocks**/MyMock.ts`, `.eslintrc.js`, `setupTests.ts`, or `api-report.md`. Explained differently, it is only files that affect the published package that need changesets, such as source files and additional resources like `package.json`, `README.md`, `config.d.ts`, etc.
|
||||
- When tweaking a change that has not yet been released, you can rely on and potentially modify the existing changeset instead.
|
||||
- Changes that do not belong to a published packages, either because it's not a package at all, such as `docs/`, or because the package is private, such as `packages/app`.
|
||||
- Changes that do not end up having an effect on the published package, such as whitespace fixes or code formatting changes. Although it's also fine to have a short changeset for these kind of changes too.
|
||||
|
||||
### Changeset Example
|
||||
|
||||
Consider the following scenario for a changeset:
|
||||
|
||||
A new `EntityList` component has been added to `plugins/catalog-react`.
|
||||
|
||||
Below are examples of a good and three bad changesets for that change.
|
||||
|
||||
**GOOD**
|
||||
|
||||
```md
|
||||
---
|
||||
'@backstage/plugin-catalog-react': minor
|
||||
---
|
||||
|
||||
Added a new `EntityList` component that can be used to display detailed information about a list of entities.
|
||||
```
|
||||
|
||||
The `@backstage/plugin-catalog-react` package has reached version `1.x`, which means that feature additions that aren't breaking should be a `minor` change. We don't bother with too much documentation, keeping it short and sweet. The main purpose is to inform users that this new component exists and to give them an idea of how they can use it.
|
||||
|
||||
**BAD**
|
||||
|
||||
```md
|
||||
---
|
||||
'@backstage/plugin-catalog-react': minor
|
||||
'@backstage/plugin-catalog': minor
|
||||
---
|
||||
|
||||
Added `EntityList` component.
|
||||
|
||||
Fixed a bug in the catalog index page.
|
||||
```
|
||||
|
||||
This changeset is too short, it's best to give users an idea of how they can benefit from the new addition.
|
||||
|
||||
It also includes changes affecting both the Catalog and Catalog React library. It should be split into two separate changesets for each of the two packages, otherwise we'll end up with redundant and unrelated information in both changelogs.
|
||||
|
||||
**BAD**
|
||||
|
||||
```md
|
||||
---
|
||||
'@backstage/plugin-catalog-react': major
|
||||
---
|
||||
|
||||
Added a new `EntityList` component that can be used to display detailed information about a list of entities. The component looks like this:
|
||||
|
||||
|
||||
|
||||
It accepts the following properties:
|
||||
|
||||
- entities - The entities that should be listed.
|
||||
- title - An optional formatting function for the list titles.
|
||||
- dialog - An optional component that overrides the default details dialog.
|
||||
```
|
||||
|
||||
This changeset is getting too detailed. It's not always bad to get this much into the weeds, but keep in mind that changesets are not easy to browse when searching for information about specific APIs. It's better to document things like this separately and keep the changeset more lean. Also avoid linking to assets in changesets, keep them text-only.
|
||||
|
||||
The change is also marked as a breaking `major` change. This should be changed to `minor` since adding new APIs is never a breaking change.
|
||||
|
||||
**BAD**
|
||||
|
||||
```md
|
||||
---
|
||||
'@backstage/plugin-catalog-react': patch
|
||||
---
|
||||
|
||||
Added a new `EntityList` component that can be used to display detailed information about a list of entities. The `ListView` component was also refactored in order to make it possible to reuse it between the new `EntityList` and `KindList` components.
|
||||
```
|
||||
|
||||
Assuming that the `ListView` component is not public API, this changeset goes into details that are not interesting to the user of the package. Internal changes do not need to be highlighted in changesets. If an internal refactor is the only change then it's alright to say something short like "Internal refactor to improve code reuse", but otherwise those details should be left out.
|
||||
|
||||
The `@backstage/plugin-catalog-react` package has also reached `1.x`, which means that new features should be introduced through a `minor` bump. We'd only use `patch` bumps for minor changes or fixes that do not affect the public API.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
Identifying breaking changes can be quite tricky. You need to look at the changes from both the point of view of consumers and producers of APIs, as well as behavioral changes. In this section we explore a couple of methods for identifying whether a change is breaking or not.
|
||||
|
||||
### Behavioral Changes
|
||||
|
||||
These are changes where the behavior of the code changes, but the public API is unchanged or doesn't have any breaking changes. They can be anything from tiny tweaks, like adding a bit of padding to a visual element, to a complete redesign and refactor of an entire plugin.
|
||||
|
||||
It's hard to set up exact rules for when a behavioral change is breaking or not. In some cases it's obvious, for example if you remove important functionality of a system, while in other cases it can be very hard to tell. In the end what's important is whether a significant number of users of the package will be negatively impacted by the change. One question that you can ask yourself here is "is it likely that there are users that don't want the new behavior, or will need to change their code to adapt to the new behavior?" If the answer is yes, then it's likely a breaking change. You do also want to keep [xkcd.com/1172](https://xkcd.com/1172/) in mind though.
|
||||
|
||||
Note that even a bug fix can be considered a breaking change in some situations. One thing to lean on in that case is what the _documented_ behavior is. If the current behavior does not match the documented behavior, then a change to match the documentation is generally not a breaking change. That is unless it is likely that there are a significant number of users that will be impacted by the change.
|
||||
|
||||
For tricky behavioral changes you may simply need to let end users provide feedback. This can be done either by hiding the new behavior behind an experimental feature switch, or by releasing the change early on in the release cycle, preferably in the first or second `next`-line release. Be ready to respond to feedback and potentially revert the change if needed.
|
||||
|
||||
### Public API Changes
|
||||
|
||||
Typescript is a huge help when it comes to identifying breaking changes, as well as the API Reports that we generate for all packages. Most of the time it is enough to only look at the API Reports to determine whether a change is breaking or not. If you determine that a change is breaking at the TypeScript level, then it is a breaking change.
|
||||
|
||||
In this section we will be talking about changed "types", but by that we mean any kind of exported symbol from packages, such as TypeScript types aliases or interfaces, functions, classes, constants, etc.
|
||||
|
||||
#### API Reports
|
||||
|
||||
We generate API Reports using the [API Extractor](https://api-extractor.com/) tool. These reports are generated for most packages in the Backstage repository, and are stored in the `api-report.md` file of each package. For CLI package we use custom tooling, and instead store the result in `cli-report.md`. Whenever the public API of a package changes, the API Report needs to be updated to reflect the new state of the API. Our CI checks will fail if the API reports are not up to date in a pull request.
|
||||
|
||||
Each API report contains a list of all the exported types of each package. As long as the API report does not have any warnings it will contain the full publicly facing API of the package, meaning you do not need to consider any other changes to the package from the point of view of TypeScript API stability.
|
||||
|
||||
Exported types can be marked with either `@public`, `@alpha` or `@beta` release tags. It is only the `@public` exports that we consider to be part of the stable API. The `@alpha` and `@beta` exports are considered unstable and can be changed at any time without needing a breaking package versions bump. However, this **ONLY** applies if the package has been configured to use experimental type builds, which looks like this in `package.json`:
|
||||
|
||||
```json
|
||||
"build": "backstage-cli package build --experimental-type-build"
|
||||
```
|
||||
|
||||
If a package does not have this configuration, then all exported types are considered stable, even if they are marked as `@alpha` or `@beta`.
|
||||
|
||||
#### Type Contract Direction
|
||||
|
||||
An important distinction to make when looking at changes to an API Report is the direction of the contract of a changed type, that is, whether it's used as input or output from the user's point of view. In the next two sections we'll dive into the different directions of a type contract, and how it affects whether a change is breaking or not.
|
||||
|
||||
#### Input Types
|
||||
|
||||
An input type is one where a value needs to be provided by users of the package. The most common form of input type are function, constructor, and method parameters.
|
||||
|
||||
The following is an example where `MyComponentProps` is an input type:
|
||||
|
||||
```ts
|
||||
type MyComponentProps = {
|
||||
title: string;
|
||||
size?: 'small' | 'medium' | 'large';
|
||||
};
|
||||
|
||||
function MyComponent(props: MyComponentProps): JSX.Element;
|
||||
```
|
||||
|
||||
And from the package user's point of view it would look something like this:
|
||||
|
||||
```tsx
|
||||
<MyComponent title="Hello World" size="medium" />
|
||||
```
|
||||
|
||||
When modifying an input type, any change that increases constraints are breaking. For example, if we made the `size` prop required, that would be a breaking change. Likewise, if we changed the type of `size` to `'small' | 'large'`, that would also be breaking.
|
||||
|
||||
On the other hand, it's fine to relax constraints without it being a breaking change. For example, if we made the `title` prop optional, that would not be breaking. Likewise, if we changed the type of `size` to `'small' | 'medium' | 'large' | 'huge'`, that would not be breaking either. It is also possible to add new properties without it being a breaking change, as long as they are optional.
|
||||
|
||||
There's an edge-case where completely removing a property is also considered a breaking change. That's because of TypeScript being strict and refusing unknown properties, rather than a runtime breaking change. It is typically an easy thing for consumers to fix though.
|
||||
|
||||
Another way to think about the rules for evolving input types is that the old type must be assignable to the new type. In this case for example `_props: NewComponentProps = {} as OldComponentProps`. It's not a silver bullet though, because of edge-cases like the one mentioned above.
|
||||
|
||||
#### Output Types
|
||||
|
||||
An output type is one that the user receives from the packages. One of the most obvious examples here are the top-level exports from the package itself, but it also includes for example function return types.
|
||||
|
||||
The following is an example where both `useBox` and `Box` are output types:
|
||||
|
||||
```ts
|
||||
type Box = {
|
||||
title: string;
|
||||
shape?: 'square' | 'rounded';
|
||||
};
|
||||
|
||||
function useBox(): Box;
|
||||
```
|
||||
|
||||
And from the consumer's point of view it would look something like this:
|
||||
|
||||
```ts
|
||||
const { title, shape } = useBox();
|
||||
```
|
||||
|
||||
When modifying an output type, any change that reduces constraints are breaking. For example, if we made the `title` property optional, that would be a breaking change, or if we changed the type of `shape` to `'square' | 'rounded' | 'octagon'`.
|
||||
|
||||
Adding new properties is not a breaking change, regardless of whether they are optional or not. Removing properties is on the other hand always breaking.
|
||||
|
||||
It is generally fine to increase constraints without it being a breaking change. For example, if we made the `shape` property required, that would not be breaking.
|
||||
|
||||
There are some edge-cases though, for example if `shape` was changed to just `'square'`, that would be a breaking change because consumers might be checking for `box.shape === 'rounded'`, which would then be breaking. It's typically a quite easy thing for consumers to fix though. More generally, type unions and discriminated unions are quite troublesome in output types, as both adding and removing types from them are considered breaking changes.
|
||||
|
||||
Another way to think about the rules for evolving output types is that the new type must be assignable to the old type. In this case for example `_box: OldBox = {} as NewBox`. It's not a silver bullet though, because of edge-cases like the one mentioned above.
|
||||
|
||||
#### I/O Types
|
||||
|
||||
Some types are considered both input and output types. For example, consider the following example:
|
||||
|
||||
```ts
|
||||
type Point = {
|
||||
x: number;
|
||||
y: number;
|
||||
};
|
||||
|
||||
function trimCoords(point: Point): Point;
|
||||
```
|
||||
|
||||
In this case `Point` is both an input and output type. This means that the only changes we can make to the type that aren't breaking are the intersection of allowed changes between input and output types. In practice this only allows for the addition of new optional properties. Because of this constraint it is generally best to avoid using I/O types, and keep the input separated from the output.
|
||||
|
||||
There are some cases where I/O types favor either input or output when it comes to API stability. For example, all types used by Utility APIs are I/O types, but the stability of the output is a lot more important than the stability of the input. That is because it's a lot easier for the single producer of the input interface to adapt to changes compared to all consumers of the API that use it as an output type.
|
||||
|
||||
#### Identifying the Contract Direction
|
||||
|
||||
The only way to identify the contract direction of a type is to look at the context in which it's being used. In particular this can be tricky when looking at individual type aliases and interfaces, as you need to look at the rest of the package exports to see how the type is being used.
|
||||
|
||||
One important rule is that the context considered for any type is limited to only the package in which the type is declared. Just because a type is imported in a different package and used as an input type does not make it an input type.
|
||||
|
||||
The following rules can be used to identify the direction of a type alias or interface:
|
||||
|
||||
- If the type is used in an input context, for example function parameter, then it's an input type.
|
||||
- If the type is used in an output context, for example function return type, then it's an output type.
|
||||
- If the type is referenced by another type, then it inherits the direction of that type, except if referenced through a function callback, in which case the direction is reversed.
|
||||
- If the type is used or inherits both input and output contexts, then it's an I/O type.
|
||||
- If the type is not referenced anywhere else, then it's an I/O type.
|
||||
|
||||
Below is an example of the public API of a package, with type directions assigned to each export:
|
||||
|
||||
```ts
|
||||
// I/O, used by getPoint as return type and referenced by BoxProps, an input type
|
||||
interface Point {
|
||||
x: number;
|
||||
y: number;
|
||||
}
|
||||
|
||||
// Output, since it's an exported function
|
||||
function getPoint(): Point;
|
||||
|
||||
// Input, used by Box as parameter type
|
||||
interface BoxProps {
|
||||
point?: Point
|
||||
}
|
||||
|
||||
// Output, since it's an exported function
|
||||
function Box(props: BoxProps): JSX.Element;
|
||||
|
||||
// Output, used by createWidget as return type
|
||||
interface Widget {
|
||||
...
|
||||
}
|
||||
|
||||
// Output, as it's referenced by WidgetOptions, which is an input
|
||||
// type, but the render callback causes a direction reversal
|
||||
interface WidgetProps {
|
||||
...
|
||||
}
|
||||
|
||||
// Input, just like WidgetProps this is due to the direction reversal
|
||||
// caused by the render callback
|
||||
type RenderedWidget = JSX.Element | null;
|
||||
|
||||
// Input, used by createWidget parameter type
|
||||
interface WidgetOptions {
|
||||
render(props: WidgetProps): RenderedWidget;
|
||||
}
|
||||
|
||||
// Output, since it's an exported function
|
||||
function createWidget(options: WidgetOptions): Widget;
|
||||
|
||||
// I/O, since it's not referenced anywhere else
|
||||
type LabelStyle = 'normal' | 'thin';
|
||||
|
||||
// Output, since it's an exported constant
|
||||
const LABEL_SIZE: number;
|
||||
```
|
||||
@@ -11,8 +11,8 @@ Our TypeScript style is inspired by the [style guidelines](https://github.com/Mi
|
||||
1. Use PascalCase for type names.
|
||||
1. Do not use `I` as a prefix for interface names.
|
||||
1. Use PascalCase for `enum` values.
|
||||
1. Use camelCase for function names.
|
||||
1. Use camelCase for property names and local variables.
|
||||
1. Use `camelCase` for function names.
|
||||
1. Use `camelCase` for property names and local variables.
|
||||
1. Do not use `_` as a prefix for private properties.
|
||||
1. Use whole words in names when possible.
|
||||
1. Give type parameters names prefixed with `T`, for example `Request<TBody>`.
|
||||
@@ -134,6 +134,30 @@ This section describes guidelines for designing public APIs. It can also be appl
|
||||
}
|
||||
```
|
||||
|
||||
1. When there is a significant number of arguments to a function or method, prefer to use a single options object as the argument, rather than many positional arguments.
|
||||
|
||||
```ts
|
||||
// Bad
|
||||
function createWidget(id: string, name: string, width: number) {}
|
||||
|
||||
// Good
|
||||
function createWidget(options: CreateWidgetOptions) {}
|
||||
```
|
||||
|
||||
1. Avoid arrays as return types; prefer response objects.
|
||||
|
||||
```ts
|
||||
interface UserApi {
|
||||
// Bad
|
||||
// Can only return Users without signaling additional information such as pagination.
|
||||
listUsers(): Promise<User[]>;
|
||||
|
||||
// Good
|
||||
// Easy to evolve with additional fields.
|
||||
listUsers(): Promise<ListUsersResponse>;
|
||||
}
|
||||
```
|
||||
|
||||
# Documentation Guidelines
|
||||
|
||||
We use [API Extractor](https://api-extractor.com/pages/overview/demo_docs/) to generate our documentation, which in turn uses [TSDoc](https://github.com/microsoft/tsdoc) to parse our doc comments.
|
||||
|
||||
+2
-11
@@ -216,7 +216,6 @@ catalog:
|
||||
- Component
|
||||
- API
|
||||
- Resource
|
||||
- Template
|
||||
- System
|
||||
- Domain
|
||||
- Location
|
||||
@@ -271,6 +270,8 @@ catalog:
|
||||
# Backstage example templates
|
||||
- type: file
|
||||
target: ../../plugins/scaffolder-backend/sample-templates/all-templates.yaml
|
||||
rules:
|
||||
- allow: [Template]
|
||||
# Backstage end-to-end tests of TechDocs
|
||||
- type: file
|
||||
target: ../../cypress/e2e-fixture.catalog.info.yaml
|
||||
@@ -420,16 +421,6 @@ costInsights:
|
||||
kind: 'PINTS_OF_ICE_CREAM'
|
||||
unit: 'ice cream pint'
|
||||
rate: 5.5
|
||||
homepage:
|
||||
clocks:
|
||||
- label: UTC
|
||||
timezone: UTC
|
||||
- label: NYC
|
||||
timezone: 'America/New_York'
|
||||
- label: STO
|
||||
timezone: 'Europe/Stockholm'
|
||||
- label: TYO
|
||||
timezone: 'Asia/Tokyo'
|
||||
pagerduty:
|
||||
eventsBaseUrl: 'https://events.pagerduty.com/v2'
|
||||
jenkins:
|
||||
|
||||
@@ -75,7 +75,7 @@ export const createAuthMiddleware = async (
|
||||
// Authorization header may be forwarded by plugin requests
|
||||
req.headers.authorization = `Bearer ${token}`;
|
||||
}
|
||||
if (token && token !== req.cookies.token) {
|
||||
if (token && token !== req.cookies?.token) {
|
||||
setTokenCookie(res, {
|
||||
token,
|
||||
secure,
|
||||
|
||||
@@ -106,3 +106,7 @@ There are some custom metrics that have been added to Backstage will be output f
|
||||
- `catalog_processing_duration_seconds`: Time spent executing the full processing flow
|
||||
- `catalog_processors_duration_seconds`: Time spent executing catalog processors
|
||||
- `catalog_processing_queue_delay_seconds`: The amount of delay between being scheduled for processing, and the start of actually being processed
|
||||
- `scaffolder_task_count`: Tracks successful task runs.
|
||||
- `scaffolder_task_duration`: a histogram which tracks the duration of a task run
|
||||
- `scaffolder_step_count`: a count that tracks each step run
|
||||
- `scaffolder_step_duration`: a histogram which tracks the duration of each step run
|
||||
|
||||
+3
-3
@@ -414,8 +414,8 @@ __metadata:
|
||||
linkType: hard
|
||||
|
||||
"cypress@npm:^10.0.0":
|
||||
version: 10.8.0
|
||||
resolution: "cypress@npm:10.8.0"
|
||||
version: 10.10.0
|
||||
resolution: "cypress@npm:10.10.0"
|
||||
dependencies:
|
||||
"@cypress/request": ^2.88.10
|
||||
"@cypress/xvfb": ^1.2.4
|
||||
@@ -461,7 +461,7 @@ __metadata:
|
||||
yauzl: ^2.10.0
|
||||
bin:
|
||||
cypress: bin/cypress
|
||||
checksum: c052690049980e7721e6fca563b724fde839d87d83c1478dfe26ce7d230992717c2c4028e7157bfb39ec274473e51929f49e5aab6a23c2b25cde2a439b1c3cf9
|
||||
checksum: 668a32534a527dba79754abbf98af176b80c539a12ec00058932ba2a19c794c7888323e59e738c30f726ad740c5451c31d02548a0cb7c1b1c8ad01c55a984ca2
|
||||
languageName: node
|
||||
linkType: hard
|
||||
|
||||
|
||||
@@ -1,7 +0,0 @@
|
||||
---
|
||||
id: backend
|
||||
title: Backend
|
||||
description: About Backend
|
||||
---
|
||||
|
||||
## TODO
|
||||
+54
-54
@@ -13,31 +13,31 @@ both with other plugins and the app itself.
|
||||
|
||||
Backstage provides two primary methods for plugins to communicate across their
|
||||
boundaries in client-side code. The first one being the
|
||||
[createPlugin](../reference/core-plugin-api.createplugin.md) API along with the
|
||||
[`createPlugin`](../reference/core-plugin-api.createplugin.md) API along with the
|
||||
extensions that it can provide, and the second one being Utility APIs. While the
|
||||
[createPlugin](../reference/core-plugin-api.createplugin.md) API is focused on
|
||||
[`createPlugin`](../reference/core-plugin-api.createplugin.md) API is focused on
|
||||
the initialization plugins and the app, the Utility APIs provide ways for
|
||||
plugins to communicate during their entire life cycle.
|
||||
|
||||
## Consuming APIs
|
||||
|
||||
Each Utility API is tied to an [ApiRef](../reference/core-plugin-api.apiref.md)
|
||||
Each Utility API is tied to an [`ApiRef`](../reference/core-plugin-api.apiref.md)
|
||||
instance, which is a global singleton object without any additional state or
|
||||
functionality, its only purpose is to reference Utility APIs.
|
||||
[ApiRef](../reference/core-plugin-api.apiref.md)s are created using
|
||||
[createApiRef](../reference/core-plugin-api.createapiref.md), which is exported
|
||||
by [@backstage/core-plugin-api](../reference/core-plugin-api.md). There are also
|
||||
[`ApiRef`](../reference/core-plugin-api.apiref.md)s are created using
|
||||
[`createApiRef`](../reference/core-plugin-api.createapiref.md), which is exported
|
||||
by [`@backstage/core-plugin-api`](../reference/core-plugin-api.md). There are also
|
||||
many predefined Utility APIs in
|
||||
[@backstage/core-plugin-api](../reference/core-plugin-api.md), and they're all
|
||||
[`@backstage/core-plugin-api`](../reference/core-plugin-api.md), and they're all
|
||||
exported with a name of the pattern `*ApiRef`, for example
|
||||
[errorApiRef](../reference/core-plugin-api.errorapiref.md).
|
||||
[`errorApiRef`](../reference/core-plugin-api.errorapiref.md).
|
||||
|
||||
To access one of the Utility APIs inside a React component, use the
|
||||
[useApi](../reference/core-plugin-api.useapi.md) hook exported by
|
||||
[@backstage/core-plugin-api](../reference/core-plugin-api.md), or the
|
||||
[withApis](../reference/core-plugin-api.withapis.md) HOC if you prefer class
|
||||
[`useApi`](../reference/core-plugin-api.useapi.md) hook exported by
|
||||
[`@backstage/core-plugin-api`](../reference/core-plugin-api.md), or the
|
||||
[`withApis`](../reference/core-plugin-api.withapis.md) HOC if you prefer class
|
||||
components. For example, the
|
||||
[ErrorApi](../reference/core-plugin-api.errorapi.md) can be accessed like this:
|
||||
[`ErrorApi`](../reference/core-plugin-api.errorapi.md) can be accessed like this:
|
||||
|
||||
```tsx
|
||||
import React from 'react';
|
||||
@@ -56,14 +56,14 @@ export const MyComponent = () => {
|
||||
```
|
||||
|
||||
Note that there is no explicit type given for
|
||||
[ErrorApi](../reference/core-plugin-api.errorapi.md). This is because the
|
||||
[errorApiRef](../reference/core-plugin-api.errorapiref.md) has the type
|
||||
embedded, and [useApi](../reference/core-plugin-api.useapi.md) is able to infer
|
||||
[`ErrorApi`](../reference/core-plugin-api.errorapi.md). This is because the
|
||||
[`errorApiRef`](../reference/core-plugin-api.errorapiref.md) has the type
|
||||
embedded, and [`useApi`](../reference/core-plugin-api.useapi.md) is able to infer
|
||||
the type.
|
||||
|
||||
Also note that consuming Utility APIs is not limited to plugins, it can be done
|
||||
from any component inside Backstage, including the ones in
|
||||
[@backstage/core-plugin-api](../reference/core-plugin-api.md). The only
|
||||
[`@backstage/core-plugin-api`](../reference/core-plugin-api.md). The only
|
||||
requirement is that they are beneath the `AppProvider` in the react tree.
|
||||
|
||||
## Supplying APIs
|
||||
@@ -71,15 +71,15 @@ requirement is that they are beneath the `AppProvider` in the react tree.
|
||||
### API Factories
|
||||
|
||||
APIs are registered in the form of
|
||||
[ApiFactories](../reference/core-plugin-api.apifactory.md), which encapsulate
|
||||
[`ApiFactory`](../reference/core-plugin-api.apifactory.md) instances, which encapsulate
|
||||
the process of instantiating an API. It is a collection of three things: the
|
||||
[ApiRef](../reference/core-plugin-api.apiref.md) of the API to instantiate, a
|
||||
[`ApiRef`](../reference/core-plugin-api.apiref.md) of the API to instantiate, a
|
||||
list of all required dependencies, and a factory function that returns a new API
|
||||
instance.
|
||||
|
||||
For example, this is the default
|
||||
[ApiFactory](../reference/core-plugin-api.apifactory.md) for the
|
||||
[ErrorApi](../reference/core-plugin-api.errorapi.md):
|
||||
[`ApiFactory`](../reference/core-plugin-api.apifactory.md) for the
|
||||
[`ErrorApi`](../reference/core-plugin-api.errorapi.md):
|
||||
|
||||
```ts
|
||||
createApiFactory({
|
||||
@@ -93,25 +93,25 @@ createApiFactory({
|
||||
});
|
||||
```
|
||||
|
||||
In this example the [errorApiRef](../reference/core-plugin-api.errorapiref.md)
|
||||
In this example the [`errorApiRef`](../reference/core-plugin-api.errorapiref.md)
|
||||
is our API, which encapsulates the
|
||||
[ErrorApi](../reference/core-plugin-api.errorapi.md) type. The
|
||||
[alertApiRef](../reference/core-plugin-api.alertapiref.md) is our single
|
||||
[`ErrorApi`](../reference/core-plugin-api.errorapi.md) type. The
|
||||
[`alertApiRef`](../reference/core-plugin-api.alertapiref.md) is our single
|
||||
dependency, which we give the name `alertApi`, and is then passed on to the
|
||||
factory function, which returns an implementation of the
|
||||
[ErrorApi](../reference/core-plugin-api.errorapi.md).
|
||||
[`ErrorApi`](../reference/core-plugin-api.errorapi.md).
|
||||
|
||||
The [createApiFactory](../reference/core-plugin-api.createapifactory.md)
|
||||
The [`createApiFactory`](../reference/core-plugin-api.createapifactory.md)
|
||||
function is a thin wrapper that enables TypeScript type inference. You may
|
||||
notice that there are no type annotations in the above example, and that is
|
||||
because we're able to infer all types from the
|
||||
[ApiRef](../reference/core-plugin-api.apiref.md)s. TypeScript will make sure
|
||||
[`ApiRef`](../reference/core-plugin-api.apiref.md)s. TypeScript will make sure
|
||||
that the return value of the `factory` function matches the type embedded in
|
||||
`api`'s [ApiRef](../reference/core-plugin-api.apiref.md), in this case the
|
||||
[ErrorApi](../reference/core-plugin-api.errorapi.md). It will also match the
|
||||
`api`'s [`ApiRef`](../reference/core-plugin-api.apiref.md), in this case the
|
||||
[`ErrorApi`](../reference/core-plugin-api.errorapi.md). It will also match the
|
||||
types between the `deps` and the parameters of the `factory` function, again
|
||||
using the type embedded within the
|
||||
[ApiRef](../reference/core-plugin-api.apiref.md)s.
|
||||
[`ApiRef`](../reference/core-plugin-api.apiref.md)s.
|
||||
|
||||
## Registering API Factories
|
||||
|
||||
@@ -123,13 +123,13 @@ app, and the app itself.
|
||||
|
||||
Starting with the Backstage core library, it provides implementations for all of
|
||||
the core APIs. The core APIs are the ones exported by
|
||||
[@backstage/core-plugin-api](../reference/core-plugin-api.md), such as the
|
||||
[errorApiRef](../reference/core-plugin-api.errorapiref.md) and
|
||||
[configApiRef](../reference/core-plugin-api.configapiref.md).
|
||||
[`@backstage/core-plugin-api`](../reference/core-plugin-api.md), such as the
|
||||
[`errorApiRef`](../reference/core-plugin-api.errorapiref.md) and
|
||||
[`configApiRef`](../reference/core-plugin-api.configapiref.md).
|
||||
|
||||
The core APIs are loaded for any app created with
|
||||
[createApp](../reference/app-defaults.createapp.md) from
|
||||
[@backstage/core-plugin-api](../reference/app-defaults.md), which means that
|
||||
[`createApp`](../reference/app-defaults.createapp.md) from
|
||||
[`@backstage/core-plugin-api`](../reference/app-defaults.md), which means that
|
||||
there is no step that needs to be taken to include these APIs in an app.
|
||||
|
||||
### Plugin APIs
|
||||
@@ -137,13 +137,13 @@ there is no step that needs to be taken to include these APIs in an app.
|
||||
In addition to the core APIs, plugins can define and export their own APIs.
|
||||
While doing so they should usually also provide default implementations of their
|
||||
own APIs, for example, the `catalog` plugin exports `catalogApiRef`, and also
|
||||
supplies a default [ApiFactory](../reference/core-plugin-api.apifactory.md) of
|
||||
supplies a default [`ApiFactory`](../reference/core-plugin-api.apifactory.md) of
|
||||
that API using the `CatalogClient`. There is one restriction to plugin-provided
|
||||
API Factories: plugins may not supply factories for core APIs, trying to do so
|
||||
will cause the app to refuse to start.
|
||||
|
||||
Plugins supply their APIs through the `apis` option of
|
||||
[createPlugin](../reference/core-plugin-api.createplugin.md), for example:
|
||||
[`createPlugin`](../reference/core-plugin-api.createplugin.md), for example:
|
||||
|
||||
```ts
|
||||
export const techdocsPlugin = createPlugin({
|
||||
@@ -168,7 +168,7 @@ Lastly, the app itself is the final point where APIs can be added, and what has
|
||||
the final say in what APIs will be loaded at runtime. The app may override the
|
||||
factories for any of the core or plugin APIs, with the exception of the config,
|
||||
app theme, and identity APIs. These are static APIs that are tied into the
|
||||
[createApp](../reference/app-defaults.createapp.md) implementation, and
|
||||
[`createApp`](../reference/app-defaults.createapp.md) implementation, and
|
||||
therefore not possible to override.
|
||||
|
||||
Overriding APIs is useful for apps that want to switch out behavior to tailor it
|
||||
@@ -231,19 +231,19 @@ const app = createApp({
|
||||
```
|
||||
|
||||
Note that the above line will cause an error if `IgnoreErrorApi` does not fully
|
||||
implement the [ErrorApi](../reference/core-plugin-api.errorapi.md), as it is
|
||||
implement the [`ErrorApi`](../reference/core-plugin-api.errorapi.md), as it is
|
||||
checked by the type embedded in the
|
||||
[errorApiRef](../reference/core-plugin-api.errorapiref.md) at compile time.
|
||||
[`errorApiRef`](../reference/core-plugin-api.errorapiref.md) at compile time.
|
||||
|
||||
## Defining custom Utility APIs
|
||||
|
||||
Plugins are free to define their own Utility APIs. Simply define the TypeScript
|
||||
interface for the API, and create an
|
||||
[ApiRef](../reference/core-plugin-api.apiref.md) using
|
||||
[createApiRef](../reference/core-plugin-api.createapiref.md) exported from
|
||||
[@backstage/core-plugin-api](../reference/core-plugin-api.md). Also be sure to
|
||||
[`ApiRef`](../reference/core-plugin-api.apiref.md) using
|
||||
[`createApiRef`](../reference/core-plugin-api.createapiref.md) exported from
|
||||
[`@backstage/core-plugin-api`](../reference/core-plugin-api.md). Also be sure to
|
||||
provide at least one implementation of the API, and to declare a default factory
|
||||
for the API in [createPlugin](../reference/core-plugin-api.createplugin.md).
|
||||
for the API in [`createPlugin`](../reference/core-plugin-api.createplugin.md).
|
||||
|
||||
Custom Utility APIs can be either public or private, which is up to the plugin
|
||||
to choose. Private APIs do not expose an external API surface, and it's
|
||||
@@ -255,16 +255,16 @@ backwards compatibility of public APIs, as you may otherwise break apps that are
|
||||
using your plugin.
|
||||
|
||||
To make an API public, simply export the
|
||||
[ApiRef](../reference/core-plugin-api.apiref.md) of the API, and any associated
|
||||
[`ApiRef`](../reference/core-plugin-api.apiref.md) of the API, and any associated
|
||||
types. To make an API private, just avoid exporting the
|
||||
[ApiRef](../reference/core-plugin-api.apiref.md), but still be sure to supply a
|
||||
default factory to [createPlugin](../reference/core-plugin-api.createplugin.md).
|
||||
[`ApiRef`](../reference/core-plugin-api.apiref.md), but still be sure to supply a
|
||||
default factory to [`createPlugin`](../reference/core-plugin-api.createplugin.md).
|
||||
|
||||
Private APIs are useful for plugins that want to depend on other APIs outside of
|
||||
React components, but not have to expose an entire API surface to maintain. When
|
||||
using private APIs, it is fine to use the `typeof` of an implementing class as
|
||||
the type parameter passed to
|
||||
[createApiRef](../reference/core-plugin-api.createapiref.md), while public APIs
|
||||
[`createApiRef`](../reference/core-plugin-api.createapiref.md), while public APIs
|
||||
should always define a separate TypeScript interface type.
|
||||
|
||||
Plugins may depend on APIs from other plugins, both in React components and as
|
||||
@@ -273,13 +273,13 @@ dependencies between plugins.
|
||||
|
||||
## Architecture
|
||||
|
||||
The [ApiRef](../reference/core-plugin-api.apiref.md) instances mentioned above
|
||||
The [`ApiRef`](../reference/core-plugin-api.apiref.md) instances mentioned above
|
||||
provide a point of indirection between consumers and producers of Utility APIs.
|
||||
It allows for plugins and components to depend on APIs in a type-safe way,
|
||||
without having a direct reference to a concrete implementation of the APIs. The
|
||||
Apps are also given a lot of flexibility in what implementations to provide. As
|
||||
long as they adhere to the contract established by an
|
||||
[ApiRef](../reference/core-plugin-api.apiref.md), they are free to choose any
|
||||
[`ApiRef`](../reference/core-plugin-api.apiref.md), they are free to choose any
|
||||
implementation they want.
|
||||
|
||||
The figure below shows the relationship between
|
||||
@@ -304,16 +304,16 @@ The indirection provided by Utility APIs also makes it straightforward to test
|
||||
components that depend on APIs, and to provide a standard common development
|
||||
environment for plugins. A proper test wrapper with mocked API implementations
|
||||
is not yet ready, but it will be provided as a part of
|
||||
[@backstage/test-utils](../reference/test-utils.md). It will provide mocked
|
||||
[`@backstage/test-utils`](../reference/test-utils.md). It will provide mocked
|
||||
variants of APIs, with additional methods for asserting a component's
|
||||
interaction with the API.
|
||||
|
||||
The common development environment for plugins is included in
|
||||
[@backstage/dev-utils](../reference/dev-utils.md), where the exported
|
||||
[createDevApp](../reference/dev-utils.createdevapp.md) function creates an
|
||||
[`@backstage/dev-utils`](../reference/dev-utils.md), where the exported
|
||||
[`createDevApp`](../reference/dev-utils.createdevapp.md) function creates an
|
||||
application with implementations for all core APIs already present. Contrary to
|
||||
the method for wiring up Utility API implementations in an app created with
|
||||
[createApp](../reference/app-defaults.createapp.md),
|
||||
[createDevApp](../reference/dev-utils.createdevapp.md) uses automatic dependency
|
||||
[`createApp`](../reference/app-defaults.createapp.md),
|
||||
[`createDevApp`](../reference/dev-utils.createdevapp.md) uses automatic dependency
|
||||
injection. This is to make it possible to replace any API implementation, and
|
||||
having that be reflected in dependents of that API.
|
||||
|
||||
@@ -15,7 +15,7 @@ thing well". The module would be consumed
|
||||
(`const localName = require('the-module');`) without having to know the internal
|
||||
structure.
|
||||
|
||||
Now, ESModules are the primary authoring format. They have numerous benefits,
|
||||
Now, `ESModules` are the primary authoring format. They have numerous benefits,
|
||||
such as compile-time verification of exports, and standards-defined semantics.
|
||||
They have a similar mechanism known as "default exports", which allows for a
|
||||
consumer to `import localName from 'the-module';`. This is implicitly the same
|
||||
|
||||
@@ -34,5 +34,5 @@ Records should be stored under the `architecture-decisions` directory.
|
||||
|
||||
## Superseding an ADR
|
||||
|
||||
If an ADR supersedes an older ADR then the older ADR's status is changed to
|
||||
superseded by ADR-XXXX and links to the new ADR.
|
||||
If an ADR supersedes an older ADR then the status of the older ADR is changed to
|
||||
"superseded by ADR-XXXX", and links to the new ADR.
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user