paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 45 Packages Projects Releases Wiki Activity

Merge branch 'backstage:master' into techdocs-config-md

Browse Source
This commit is contained in:
Saptarshi Mula
2026-01-21 22:06:18 +05:30
committed by GitHub
parent e4c1ba6a53 711592e3b9
commit 3934a9f990
2072 changed files with 107302 additions and 29951 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/api/deprecations.md
+1 -1
View File
@@ -124,7 +124,7 @@ createApiFactory({
```
Provider specific factory implementations, copy the code you need into the
factory method depending on which apiRef you previously used.
factory method depending on which API ref you previously used.
```ts
// samlAuthApiRef
docs/api/utility-apis.md
+54 -54
View File
@@ -10,31 +10,31 @@ Backstage plugins strive to be self-contained, with as much functionality as pos
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`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html) 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`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html) 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)
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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)s are created using
[`createApiRef`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiRef.html), which is exported
by [`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html). 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`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html), and they're all
exported with a name of the pattern `*ApiRef`, for example
[`errorApiRef`](../reference/core-plugin-api.errorapiref.md).
[`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html).
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`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.useApi.html) hook exported by
[`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html), or the
[`withApis`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.withApis.html) HOC if you prefer class
components. For example, the
[`ErrorApi`](../reference/core-plugin-api.errorapi.md) can be accessed like this:
[`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html) can be accessed like this:
```tsx
import { useApi, errorApiRef } from '@backstage/core-plugin-api';
@@ -52,14 +52,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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html). This is because the
[`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html) has the type
embedded, and [`useApi`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.useApi.html) 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`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html). The only
requirement is that they are beneath the `AppProvider` in the react tree.
## Supplying APIs
@@ -67,15 +67,15 @@ requirement is that they are beneath the `AppProvider` in the react tree.
### API Factories
APIs are registered in the form of
[`ApiFactory`](../reference/core-plugin-api.apifactory.md) instances, which encapsulate
[`ApiFactory`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiFactory.html) 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html) 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiFactory.html) for the
[`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html):
```ts
createApiFactory({
@@ -89,25 +89,25 @@ createApiFactory({
});
```
In this example, the [`errorApiRef`](../reference/core-plugin-api.errorapiref.md)
In this example, the [`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html)
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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html) type. The
[`alertApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.alertApiRef.html) 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html).
The [`createApiFactory`](../reference/core-plugin-api.createapifactory.md)
The [`createApiFactory`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiFactory.html)
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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html), in this case the
[`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html). 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)s.
## Registering API Factories
@@ -119,13 +119,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`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html), such as the
[`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html) and
[`configApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.configApiRef.html).
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`](https://backstage.io/api/stable/functions/_backstage_app-defaults.createApp.html) from
[`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html), which means that
there is no step that needs to be taken to include these APIs in an app.
### Plugin APIs
@@ -133,13 +133,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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiFactory.html) 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`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html), for example:
```ts
export const techdocsPlugin = createPlugin({
@@ -164,7 +164,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`](https://backstage.io/api/stable/functions/_backstage_app-defaults.createApp.html) implementation and
therefore, not possible to override.
Overriding APIs is useful for apps that want to switch out behavior to tailor it
@@ -227,33 +227,33 @@ 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html), as it is
checked by the type embedded in the
[`errorApiRef`](../reference/core-plugin-api.errorapiref.md) at compile time.
[`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html) 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html) using
[`createApiRef`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiRef.html) exported from
[`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html). 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`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html).
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 therefore possible to make breaking changes to the API without affecting other users of the plugin. If an API is made public, however, it opens up for other plugins to make use of the API, and it also makes it possible for users for your plugin to override the API in the app. It is, however, important to maintain backward 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html) 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html), but still be sure to supply a
default factory to [`createPlugin`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html).
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`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiRef.html), 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
@@ -262,13 +262,13 @@ dependencies between plugins.
## Architecture
The [`ApiRef`](../reference/core-plugin-api.apiref.md) instances mentioned above
The [`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html) 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`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html), they are free to choose any
implementation they want.
The figure below shows the relationship between
@@ -291,16 +291,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`](https://backstage.io/api/stable/modules/_backstage_test-utils.html). 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`](https://backstage.io/api/stable/modules/_backstage_dev-utils.html), where the exported
[`createDevApp`](https://backstage.io/api/stable/functions/_backstage_dev-utils.createDevApp.html) 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`](https://backstage.io/api/stable/functions/_backstage_app-defaults.createApp.html),
[`createDevApp`](https://backstage.io/api/stable/functions/_backstage_dev-utils.createDevApp.html) 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.
docs/assets/getting-started/create-app-output.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 306 KiB

After

Width:  |  Height:  |  Size: 122 KiB

docs/assets/getting-started/login-to-app-as-guest-user.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

docs/assets/getting-started/portal.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 132 KiB

After

Width:  |  Height:  |  Size: 111 KiB

docs/auth/github/provider.md
+1
View File
@@ -80,6 +80,7 @@ This provider includes several resolvers out of the box that you can use:
- `emailMatchingUserEntityProfileEmail`: Matches the email address from the auth provider with the User entity that has a matching `spec.profile.email`. If no match is found, it will throw a `NotFoundError`.
- `emailLocalPartMatchingUserEntityName`: Matches the [local part](https://en.wikipedia.org/wiki/Email_address#Local-part) of the email address from the auth provider with the User entity that has a matching `name`. If no match is found, it will throw a `NotFoundError`.
- `usernameMatchingUserEntityName`: Matches the username from the auth provider with the User entity that has a matching `name`. If no match is found, it will throw a `NotFoundError`.
- `userIdMatchingUserEntityAnnotation`: Matches the GitHub user ID with the User entity that has a matching `github.com/user-id`. If no match is found, it will throw a `NotFoundError`.
:::note Note
docs/auth/gitlab/provider.md
+1
View File
@@ -72,6 +72,7 @@ This provider includes several resolvers out of the box that you can use:
- `emailMatchingUserEntityProfileEmail`: Matches the email address from the auth provider with the User entity that has a matching `spec.profile.email`. If no match is found, it will throw a `NotFoundError`.
- `emailLocalPartMatchingUserEntityName`: Matches the [local part](https://en.wikipedia.org/wiki/Email_address#Local-part) of the email address from the auth provider with the User entity that has a matching `name`. If no match is found, it will throw a `NotFoundError`.
- `usernameMatchingUserEntityName`: Matches the username from the auth provider with the User entity that has a matching `name`. If no match is found, it will throw a `NotFoundError`.
- `userIdMatchingUserEntityAnnotation`: Matches the GitLab user ID with the User entity that has a matching `gitlab.com/user-id` annotation (or `{integration-host}/user-id` for self-hosted GitLab instances). If no match is found, it will throw a `NotFoundError`.
:::note Note
docs/auth/index.md
+37 -1
View File
@@ -340,7 +340,7 @@ The method with which frontend plugins request access to third-party services is
through [Utility APIs](../api/utility-apis.md) for each service provider. These
are all suffixed with `*AuthApiRef`, for example `githubAuthApiRef`. For a
full list of providers, see the
[@backstage/core-plugin-api](../reference/core-plugin-api.md#variables) reference.
[@backstage/core-plugin-api](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.index.html#alertapiref) reference.
## Custom Authentication Provider
@@ -459,6 +459,42 @@ providerFactories: {
},
```
In the new backend system you can leverage the `authProvidersExtensionPoint` for this:
```ts
// your-auth-plugin-module.ts
export const gheAuth = createBackendModule({
// This ID must be exactly "auth" because that's the plugin it targets
pluginId: 'auth',
// This ID must be unique, but can be anything
moduleId: 'ghe-auth-provider',
register(reg) {
reg.registerInit({
deps: {
providers: authProvidersExtensionPoint,
logger: coreServices.logger,
},
async init({ providers, logger }) {
providers.registerProvider({
// This ID must match the actual provider config, e.g. addressing
// auth.providers.ghe means that this must be "ghe".
providerId: 'ghe',
factory: createOAuthProviderFactory({
authenticator: githubAuthenticator,
signInResolverFactories: {
...commonSignInResolvers,
},
}),
});
},
});
},
});
// backend index.ts
backend.add(gheAuth);
```
## Configuring token issuers
By default, the Backstage authentication backend generates and manages its own signing keys automatically for any issued
docs/auth/oidc.md
+94 -102
View File
@@ -1,7 +1,7 @@
---
id: oidc
title: OIDC provider from scratch
description: This section shows how to use an OIDC provider from scratch, same steps apply for custom providers.
description: This section shows how to enable and use the Backstage OIDC provider.
---
:::info
@@ -11,78 +11,65 @@ system, you may want to read [its own article](https://github.com/backstage/back
instead, and [consider migrating](../backend-system/building-backends/08-migrating.md)!
:::
This section shows how to use an OIDC provider from scratch, same steps apply for custom
providers. Please note these steps are for using a provider, not how to implement one,
and Backstage recommends creating custom providers specific to the IDP, so we'll use a
`azureOIDC` provider throughout this example, feel free to change any of those refs
to your provider name.
This section shows how to enable and use the Backstage OIDC provider.
## Summary
To add providers not enabled by default like OIDC, we need to follow some steps, we
assume you already have a sign-in page to which we'll add the provider so users can
sign in through the provider. In simple steps here's how you enable the provider:
OIDC is a protocol which has numerous implementations. It's likely that many of your users won't know what the OIDC **protocol** is, but they will recognise your OIDC **implementation**. Backstage supplies a generic `oidc` authorization strategy. You should re-badge this with the name and branding of your OIDC implementation, so that your users will recognise it on the Backstage sign-in page.
For example, if your organization uses [Keycloak](https://www.keycloak.org), you would re-badge the OIDC provider as `Keycloak` and tell users to `Sign In using Keycloak`.
## Steps
The Backstage OIDC provider is not enabled by default. You need to manually enable the provider, and tell it which OIDC server you want to use.
To enable the Backstage OIDC provider:
- Create an API reference to identify the provider.
- Create the API factory that will handle the authentication.
- Add or reuse an auth provider so you can authenticate.
- Add or reuse a resolver to handle the result from the authentication.
- Configure the provider to access your 3rd party auth solution.
- Add the provider to sign in page so users can login with it.
- Add the provider to the Backstage sign-in page.
For simplicity, we assume that you only have a single OIDC provider in your Backstage installation. (If you need to have multiple OIDC providers in Backstage, the steps will be different.)
We'll explain each step more in detail next.
### The API reference
### The API Reference
An API reference exist for the sake of **Dependency Injection**, check [Utility APIs][4]
for extended explanation.
An API reference exists to enable **Dependency Injection**. (See [Utility APIs][4] for an extended explanation.)
In this OIDC example, we'll create the API reference directly in the
`packages/app/src/apis.ts` file, it is not a requirement to put the reference in this
file. Any location will do as long as it's available to be imported to where the API
factory is, as well as easily accessible to the rest of the application so any package
and plugin can inject the API instance when necessary.
An example of such would be when you use an auth provider from a library installed with
NPM, or any other library repository, you would import the API ref from the library.
In this example, we'll create the API ref directly in the `packages/app/src/apis.ts` file. It is not a requirement to put the ref in this file. Any location will do as long as it's available to be imported to where the API factory is, as well as easily accessible to the rest of the application so any package and plugin can inject the API instance when necessary.
```ts
export const azureOIDCAuthApiRef: ApiRef<
export const keycloakAuthApiRef: ApiRef<
OpenIdConnectApi & ProfileInfoApi & BackstageIdentityApi & SessionApi
> = createApiRef({
id: 'auth.my-custom-provider',
id: 'auth.keycloak',
});
```
Please note a few things, the ID can be anything you want as long as it doesn't conflict
with other refs, backstage recommends to use a custom name that references your custom
provider, for example we are using OIDC protocol with Azure, so we could use something
like `auth.azure.oidc` as well.
The `id` of the API ref can be anything you want, as long as it doesn't conflict with other refs. Backstage recommends to use a custom name that references your custom provider.
Also we're exporting this reference, as well as the `typings`, we need to
be able to import this reference anywhere in the app, and the `typings` will tell typescript
:::note TypeScript Note
As we're exporting this API reference, as well as the TypeScript types, we need to
be able to import this reference anywhere in the app. The types will tell TypeScript
what instance we're getting from DI when injecting the API. In this case we are defining
an API for authentication, so we tell TS that this instance complies with 4 API
interfaces:
- The OICD API that will handle authentication.
- The OIDC API that will handle authentication.
- Profile API for requesting user profile info from the auth provider in question.
- Backstage identity API to handle and associate the user profile with backstage identity.
- Session API, to handle the session the user will have while logged in.
- Session API, to handle the session the user will have while signed in.
:::
### The API Factory
### The API Factory (and auth provider)
A factory is a function that can take some parameters or dependencies and return an
instance of something, in our case it will be a function that requests some backstage
APIs and use them to create an instance of an OIDC API provider.
The Backstage API factories are part of the Backstage Dependency Injection system. The factory function runs once, when something in your Backstage app first attempts to use an instance of the API it provides. The instance is then cached by the DI system for subsequent lookups.
Please note that this function only runs (creates the instance) when somewhere else in
the app you request the DI to give you an instance of the OIDC provider using the API ref
defined above, and the DI will only run this function the first time, from then on any
other DI injection will just receive the same instance created the first time, basically
the instance is cached by the DI library, a singleton.
Let's add our OIDC API factory to the APIs array in the `packages/app/src/apis.ts` file:
Let's add a new API factory to the `apis` array in the `packages/app/src/apis.ts` file. We will tell it to use the OIDC auth provider internally.
```ts title="packages/app/src/apis.ts"
/* highlight-add-next-line */
@@ -91,26 +78,29 @@ import { OAuth2 } from '@backstage/core-app-api';
export const apis: AnyApiFactory[] = [
/* highlight-add-start */
createApiFactory({
api: azureOIDCAuthApiRef,
api: keycloakAuthApiRef,
deps: {
discoveryApi: discoveryApiRef,
oauthRequestApi: oauthRequestApiRef,
configApi: configApiRef,
},
factory: ({ discoveryApi, oauthRequestApi, configApi }) =>
// delegate auth to the OAuth2 strategy
OAuth2.create({
configApi,
discoveryApi,
oauthRequestApi,
provider: {
id: 'my-auth-provider',
title: 'My custom auth provider',
// this value MUST be 'oidc'
// it maps our Keycloak-branded sign-in provider onto Backstage's generic OIDC auth strategy
id: 'oidc',
title: 'Keycloak',
icon: () => null,
},
environment: configApi.getOptionalString('auth.environment'),
defaultScopes: ['openid', 'profile', 'email'],
popupOptions: {
// optional, used to customize login in popup size
// optional, used to customize sign-in window size
size: {
fullscreen: true,
},
@@ -125,27 +115,14 @@ export const apis: AnyApiFactory[] = [
}),
}),
/* highlight-add-end */
// ..
];
```
Please note we're importing the `OAuth2` class from `@backstage/core-app-api` effectively
delegating the authentication to it. Also we're using the `my-auth-provider` ID to tell
`OAuth2` to use the auth provider we'll define in the next section, and added the default
scopes to request ID, profile, email and user read permissions.
## The Auth Provider
The Auth Provider is responsible for authenticating with the 3rd party service, and give
us back the credentials, here's where you pick which protocol to use, be it Auth0, OAuth2,
OIDC, SAML or any other that your 3rd party IDP provider supports.
### The Resolver
Resolvers exist to map user identity from the 3rd party (in this case an azure IDP
provider) to the backstage user identity.
Resolvers exist to map the user identity from the 3rd party (in this case Keycloak) to the Backstage user identity.
The default OIDC provider has built-in resolvers, here is how you configure them:
The default OIDC provider has a choice of built-in resolvers, here is how you configure them:
```yaml title="app-config.yaml"
auth:
@@ -159,7 +136,7 @@ auth:
- resolver: emailMatchingUserEntityProfileEmail
```
But you can also write a custom resolver as well, see an example below:
If none of the built-in resolvers are suitable, you can alternatively write a custom resolver. See an example below:
```ts title="in packages/backend/src/index.ts"
/* highlight-add-start */
@@ -174,15 +151,15 @@ const myAuthProviderModule = createBackendModule({
// This ID must be exactly "auth" because that's the plugin it targets
pluginId: 'auth',
// This ID must be unique, but can be anything
moduleId: 'my-auth-provider',
moduleId: 'keycloak-auth-provider',
register(reg) {
reg.registerInit({
deps: { providers: authProvidersExtensionPoint },
async init({ providers }) {
providers.registerProvider({
// This ID must match the actual provider config, e.g. addressing
// auth.providers.azure means that this must be "azure".
providerId: 'my-auth-provider',
// auth.providers.keycloak means that this must be "keycloak".
providerId: 'keycloak',
// Use createProxyAuthProviderFactory instead if it's one of the proxy
// based providers rather than an OAuth based one
factory: createOAuthProviderFactory({
@@ -215,76 +192,91 @@ backend.add(myAuthProviderModule);
//...
```
For a more a detailed explanation about resolvers check the
[Identity Resolver][1] page.
For a more detailed explanation about resolvers check the [Identity Resolver][1] page.
### The configuration
### The Configuration
Since we are using our custom OIDC Auth Provider, we need to add a configuration based
on the provider used, in this case based on OIDC protocol (remember the 3rd party has to
support the protocol).
We will now configure our Keycloak-branded OIDC Auth Provider in Backstage, so that it can talk to our Keycloak server.
In this example we'll configure OIDC with `my-auth-provider`, to do so we need to
[Create app registration][2] in the Azure console, the only difference is that the
`http://localhost:7007/api/auth/microsoft/handler/frame` URL needs to change to
`http://localhost:7007/api/auth/my-auth-provider/handler/frame`.
The first step is to register an OIDC client app for Backstage in your Keycloak server.
Then we need to configure the env variables for the provider, based on the provider's code
in `plugins/auth-backend/src/providers/oidc/provider.ts` we need the following variables
in the `app-config.yaml`:
Then we need to configure the provider. Based on the provider's code in `plugins/auth-backend/src/providers/oidc/provider.ts` we need the following parameters in the `app-config.yaml`:
```yaml title="app-config.yaml"
auth:
environment: development
### Providing an auth.session.secret will enable session support in the auth-backend
session:
secret: ${SESSION_SECRET}
secret: ${AUTH_SESSION_SECRET}
providers:
my-auth-provider:
oidc:
development:
metadataUrl: https://example.com/.well-known/openid-configuration
clientId: ${AUTH_MY_CLIENT_ID}
clientSecret: ${AUTH_MY_CLIENT_SECRET}
clientId: ${AUTH_OIDC_CLIENT_ID}
clientSecret: ${AUTH_OIDC_CLIENT_SECRET}
```
Anything enclosed in `${}` can be replaced directly in the yaml, or provided as
environment variables, the way you obtain all these except `scope` and `prompt` is to
check the App Registration you created:
Anything enclosed in `${}` can be replaced directly in the YAML, or provided as environment variables.
#### Required Parameters
These parameters must always be set.
- `clientId`: Grab from the Overview page.
- `clientSecret`: Can only be seen when creating the secret, if you lose it you'll need a
new secret.
- `metadataUrl`: In Overview > Endpoints tab, grab OpenID Connect metadata document URL.
The OIDC provider **also** requires the `auth.session.secret` to be set.
#### Optional Parameters
These parameters have implicit default values. Don't override them unless you know what you're doing.
- `authorizationUrl` and `tokenUrl`: Open the `metadataUrl` in a browser, that json will
hold these 2 urls somewhere in there.
- `tokenEndpointAuthMethod`: Don't define it, use the default unless you know what it does.
- `tokenSignedResponseAlg`: Don't define it, use the default unless you know what it does.
- `tokenEndpointAuthMethod`
- `tokenSignedResponseAlg`
- `scope`: Only used if we didn't specify `defaultScopes` in the provider's factory,
basically the same thing.
- `prompt`: Recommended to use `auto` so the browser will request login to the IDP if the
- `prompt`: Recommended to use `auto` so the browser will request sign-in to the IDP if the
user has no active session.
- `sessionDuration` (optional): Lifespan of the user session.
- `sessionDuration`: Lifespan of the user session.
- `startUrlSearchParams`: This is a dictionary of search (query) parameters for the OIDC
authorization start URL. Don't define it unless you want to change the identity
provider's behavior. (For example, you could set the `organization` parameter to guide
users towards a particular sign-in option that your organization prefers.) **Note:** the
start URL is controlled by the browser, so this feature is only for improving the
Backstage user experience.
Note that for the time being, any change in this yaml file requires a restart of the app,
also you need to have the `session.secret` part to use OIDC (some other providers might
need this as well) to support user sessions.
:::note Config Reloading
Backstage does not yet support hot reloading of auth provider configuration. Any changes to this YAML file require a restart of Backstage.
:::
### The Sign In provider
### The Sign-In Page
The last step is to add the provider to the `SignInPage` so users can sign in with your
new provider, please follow the [Sign In Configuration][3] docs, here's where you import
and use the API reference we defined earlier.
The last step is to add the provider to the sign-in page, so users can sign in with your new provider.
If you are using the standard Backstage [`SignInPage`][3] component, you can just add it to the `providers` array like this:
```ts title="in packages/app/src/identityProviders.ts"
export const providers = [
// other providers...
{
id: 'keycloak-auth-provider',
title: 'Keycloak',
message: 'Sign In using Keycloak',
apiRef: keycloakAuthApiRef,
},
];
```
:::note Note
These steps apply to most if not all the providers, including custom providers, the main
difference between different providers will be the contents of the API factory, the code
These steps apply to most auth providers. The main
difference between providers will be the contents of the API factory, the code
in the Auth Provider Factory, the resolver, and the different variables each provider
needs in the YAML config or env variables.
:::
[1]: https://backstage.io/docs/auth/identity-resolver
[2]: https://backstage.io/docs/auth/microsoft/provider#create-an-app-registration-on-azure
[3]: https://backstage.io/docs/auth/#sign-in-configuration
[4]: https://backstage.io/docs/api/utility-apis
docs/backend-system/architecture/02-backends.md
+25
View File
@@ -38,3 +38,28 @@ Once you have added all desired features we call the `.start()` method. This cau
Underneath the hood, `createBackend` calls `createSpecializedBackend` from `@backstage/backend-app-api` which is responsible for actually creating the backend instance, without any services or features. You can think of `createBackend` more of a 'batteries included' approach, while `createSpecializedBackend` is more low level.
As mentioned previously there's also the ability to create multiple of these backends in your project so that you can split apart your backend and deploy different backends that can scale independently of each other. For instance you might choose to deploy a backend with only the catalog plugin enabled, and one with just the scaffolder plugin enabled.
### Backend Startup Result
The `Backend.start()` method returns a `BackendStartupResult` with detailed success/failure status and timing information for all plugins and modules. When startup fails, a `BackendStartupError` is thrown that includes the complete startup results, making it easier to diagnose which plugins or modules failed.
```ts
backend.start(
({ result }) => {
console.log(`Backend startup result: ${JSON.stringify(result, null, 2)}`);
},
error => {
if (error instanceof BackendStartupError) {
console.error(
`Backend startup failed: ${JSON.stringify(error.result, null, 2)}`,
);
} else {
console.error(
`Unexpected error during backend startup: ${error.message}`,
);
}
},
);
```
This information is mostly useful if you want to add additional monitoring or debugging tools to your backend. The information is a structured representation of what is already logged during startup.
docs/backend-system/building-backends/01-index.md
+1 -1
View File
@@ -14,7 +14,7 @@ system, see [migrating](./08-migrating.md).
This section covers how to set up and customize your own Backstage backend. It covers some aspects of how backend instances fit into the larger system, but for a more in-depth explanation of the role of backends in the backend system, see [the architecture section](../architecture/02-backends.md).
# Overview
## Overview
A minimal Backstage backend is very lightweight. It is a single package with a `package.json` file and a `src/index.ts` file, not counting surrounding tooling and documentation. The package is typically placed within the `packages/backend` folder of a Backstage monorepo, but that is up to you. The backend package is part of any project created with `@backstage/create-app`, so you typically do not need to create it yourself.
docs/backend-system/core-services/cache.md
+67 -6
View File
@@ -11,24 +11,84 @@ This service lets your plugin interact with a cache. It is bound to your plugin
The cache service can be configured using the `backend.cache` section in your `app-config.yaml`:
### In-Memory (default)
```yaml
backend:
cache:
store: redis # or 'valkey', 'memcache', 'memory'
store: memory
```
### Memcache
```yaml
backend:
cache:
store: memcache
connection: user:pass@cache.example.com:11211
```
### Redis
```yaml
backend:
cache:
store: redis
connection: redis://localhost:6379
# Store-specific configuration (Redis/Valkey only)
# Store-specific configuration (optional)
redis:
client:
# Optional: Global namespace prefix for all cache keys
# Global namespace prefix for all cache keys
namespace: 'my-app'
# Optional: Separator used between namespace and plugin ID (default: ':')
# Separator used between namespace and plugin ID (default: ':')
keyPrefixSeparator: ':'
# Other Redis-specific options...
clearBatchSize: 1000
useUnlink: false
```
### Valkey
```yaml
backend:
cache:
store: valkey
connection: redis://localhost:6379
# Store-specific configuration (optional)
valkey:
# Global namespace prefix for all cache keys (including separator used between namespace and plugin ID)
keyPrefix: 'my-app:'
```
### Infinispan
```yaml
backend:
cache:
store: infinispan
# Store-specific configuration (optional)
infinispan:
servers:
# IP address or hostname of the server (default: '127.0.0.1')
- host: 127.0.0.1
# Port number of the server (default: '11222')
port: 11222
# Name of the cache (default: 'cache')
cacheName: cache
mediaType: application/json
authentication:
# Whether authentication is enabled (default: 'false')
enabled: true
userName: yourusername
password: yourpassword
saslMechanism: PLAIN
```
A full list of configuration items is available [here](https://docs.jboss.org/infinispan/hotrod-clients/javascript/1.0/apidocs/module-infinispan.html), including support for backup clusters.
### Namespace Configuration
For Redis and Valkey stores, you can configure a global namespace that will be prefixed to all cache keys:
@@ -36,9 +96,10 @@ For Redis and Valkey stores, you can configure a global namespace that will be p
- **Without namespace**: Cache keys use only the plugin ID (e.g., `catalog:some-key`)
- **With namespace**: Cache keys use the format `namespace:pluginId:key` (e.g., `my-app:catalog:some-key`)
The `keyPrefixSeparator` controls what character is used between the namespace and plugin ID (defaults to `:`).
For **Redis**, `keyPrefixSeparator` controls what character is used between the namespace and plugin ID (defaults to `:`).
For **Valkey**, you set the full `keyPrefix` including the separator.
**Note**: Memory and Memcache stores do not support namespace configuration and will always use the plugin ID directly.
**Note**: In-memory, Memcache and Infinispan stores do not support namespace configuration and will always use the plugin ID directly.
## Using the service
docs/backend-system/core-services/root-instance-metadata.md
+44
View File
@@ -0,0 +1,44 @@
---
id: root-instance-metadata
title: Root Instance Metadata Service
sidebar_label: Root Instance Metadata
description: Documentation for the Root Instance Metadata service
---
The root instance metadata service provides information about the running Backstage backend instance. Currently, it provides a list of all installed backend plugins.
:::note Note
The root instance metadata service only provides information about the specific Backstage instance you're running on. In more complex deployments with multiple Backstage instances, this service will not provide a complete list of all plugins across all instances.
:::
## Using the service
The following example shows how to use the root instance metadata service in your `example` backend plugin to access the list of installed backend plugins.
```ts
import {
coreServices,
createBackendPlugin,
} from '@backstage/backend-plugin-api';
createBackendPlugin({
pluginId: 'example',
register(env) {
env.registerInit({
deps: {
instanceMetadata: coreServices.rootInstanceMetadata,
},
async init({ instanceMetadata }) {
const plugins = instanceMetadata.getInstalledPlugins();
console.log('Installed plugins:', plugins);
},
});
},
});
```
## Dynamic plugin registration
The root instance metadata service picks up plugins that are registered at start time through a `backend.start()` call. You need to restart the running backend instance to pick up newly installed plugins.
docs/conf/reading.md
+2 -2
View File
@@ -7,7 +7,7 @@ description: Documentation on Reading Backstage Configuration
## Config API
There's a common configuration API for by both frontend and backend plugins. An
API reference can be found [here](../reference/config.config.md).
API reference can be found [here](https://backstage.io/api/stable/types/_backstage_config.Config.html).
The configuration API is tailored towards failing fast in case of missing or bad
config. That's because configuration errors can always be considered programming
@@ -115,7 +115,7 @@ example `getString`. These will throw an error if there is no value available.
## Accessing ConfigApi in Frontend Plugins
The [ConfigApi](../reference/core-plugin-api.configapi.md) in the frontend is a
The [ConfigApi](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ConfigApi.html) in the frontend is a
[UtilityApi](../api/utility-apis.md). It's accessible as usual via the
`configApiRef` exported from `@backstage/core-plugin-api`:
docs/conf/user-interface/index.md
+17 -16
View File
@@ -103,13 +103,13 @@ Backstage UI is using light by default under `:root` but you can target it more
[data-theme-mode='light'] {
/* Light theme specific styles */
  --bui-bg: #f8f8f8;
  --bui-bg-surface-0: #f8f8f8;
--bui-fg-primary: #000;
}
[data-theme-mode='dark'] {
/* Dark theme specific styles */
  --bui-bg: #333333;
  --bui-bg-surface-0: #333333;
--bui-fg-primary: #fff;
}
```
@@ -122,18 +122,18 @@ We recommend starting with a core set of CSS variables to quickly achieve a bran
And if you’d like to go even further, you can target specific component class names for advanced customization.
| Token Name | Description |
| -------------------- | ----------------------------------------------------------------------------------- |
| `--bui-bg` | This is used to define the background color of your app. It will only be used once. |
| `--bui-bg-surface-1` | We ar using this color to sit on top of `--bui-bg` mostly for `Card`, `Dialog`, ... |
| `--bui-bg-surface-2` | This is for content inside elevated components. This colour is less common. |
| `--bui-bg-solid` | This is used for main actions like primary buttons. |
| `--bui-fg-solid` | This is for texts or icons on top of a solid backgrounds. |
| `--bui-fg-primary` | Your primary text or icon colours. |
| `--bui-fg-secondary` | Your secondary text or icon colours. |
| `--bui-fg-link` | Used for links. |
| `--bui-border` | Main borders around surfaces like `Card`, `Dialog`, ... |
| `--bui-font-regular` | The main font of your app. |
| Token Name | Description |
| -------------------- | --------------------------------------------------------------------------------------------- |
| `--bui-bg-surface-0` | This is used to define the background color of your app. It will only be used once. |
| `--bui-bg-surface-1` | We ar using this color to sit on top of `--bui-bg-surface-0` mostly for `Card`, `Dialog`, ... |
| `--bui-bg-surface-2` | This is for content inside elevated components. This colour is less common. |
| `--bui-bg-solid` | This is used for main actions like primary buttons. |
| `--bui-fg-solid` | This is for texts or icons on top of a solid backgrounds. |
| `--bui-fg-primary` | Your primary text or icon colours. |
| `--bui-fg-secondary` | Your secondary text or icon colours. |
| `--bui-fg-link` | Used for links. |
| `--bui-border` | Main borders around surfaces like `Card`, `Dialog`, ... |
| `--bui-font-regular` | The main font of your app. |
<details>
<summary>All available CSS variables</summary>
@@ -157,13 +157,14 @@ These colors are used for special purposes like ring, scrollbar, ...
#### Core background colors
These colors are used for the background of your application. We are mostly using for now a single elevated background for panels. `--bui-bg` should mostly use as the main background color of your app.
These colors are used for the background of your application. We are mostly using for now a single elevated background for panels. `--bui-bg-surface-0` should mostly use as the main background color of your app.
| Token Name | Description |
| ------------------------- | ------------------------------------------------ |
| `--bui-bg` | The background color of your Backstage instance. |
| `--bui-bg-surface-0` | The background color of your Backstage instance. |
| `--bui-bg-surface-1` | Use for any panels or elevated surfaces. |
| `--bui-bg-surface-2` | Use for any panels or elevated surfaces. |
| `--bui-bg-surface-3` | Use for any panels or elevated surfaces. |
| `--bui-bg-solid` | Used for solid background colors. |
| `--bui-bg-solid-hover` | Used for solid background colors when hovered. |
| `--bui-bg-solid-pressed` | Used for solid background colors when pressed. |
docs/deployment/docker.md
+4 -4
View File
@@ -53,7 +53,7 @@ Once the host build is complete, we are ready to build our image. The following
`Dockerfile` is included when creating a new app with `@backstage/create-app`:
```dockerfile
FROM node:22-bookworm-slim
FROM node:24-trixie-slim
# Set Python interpreter for `node-gyp` to use
ENV PYTHON=/usr/bin/python3
@@ -178,7 +178,7 @@ the repo root:
```dockerfile
# Stage 1 - Create yarn install skeleton layer
FROM node:22-bookworm-slim AS packages
FROM node:24-trixie-slim AS packages
WORKDIR /app
COPY backstage.json package.json yarn.lock ./
@@ -193,7 +193,7 @@ COPY plugins plugins
RUN find packages \! -name "package.json" -mindepth 2 -maxdepth 2 -exec rm -rf {} \+
# Stage 2 - Install dependencies and build packages
FROM node:22-bookworm-slim AS build
FROM node:24-trixie-slim AS build
# Set Python interpreter for `node-gyp` to use
ENV PYTHON=/usr/bin/python3
@@ -231,7 +231,7 @@ RUN mkdir packages/backend/dist/skeleton packages/backend/dist/bundle \
&& tar xzf packages/backend/dist/bundle.tar.gz -C packages/backend/dist/bundle
# Stage 3 - Build the actual backend image and install production dependencies
FROM node:22-bookworm-slim
FROM node:24-trixie-slim
# Set Python interpreter for `node-gyp` to use
ENV PYTHON=/usr/bin/python3
docs/deployment/scaling.md
+1 -1
View File
@@ -17,7 +17,7 @@ into multiple different services, each running a different set of plugins. This
is a more advanced approach and requires you to be able to route requests to
the appropriate backends based on the plugin ID. Both for ingress, but also
internal traffic between Backstage backends, which is done by creating a custom
implementation of the [DiscoveryService](../reference/backend-plugin-api.discoveryservice.md) interface. See the [backend system docs](../backend-system/building-backends/01-index.md#split-into-multiple-backends) for more details on how to separate your deployment into multiple backend instances.
implementation of the [DiscoveryService](https://backstage.io/api/stable/interfaces/_backstage_backend-plugin-api.index.DiscoveryService.html) interface. See the [backend system docs](../backend-system/building-backends/01-index.md#split-into-multiple-backends) for more details on how to separate your deployment into multiple backend instances.
Lastly, you can also replicate the Backstage deployments across multiple regions.
This is not a pattern that there is built-in support for and typically only makes
docs/faq/technical.md
+1 -1
View File
@@ -7,7 +7,7 @@ description: General technical questions about Backstage.
### What technology does Backstage use?
Backstage is a large scale [TypeScript](https://www.typescriptlang.org/)
application whose frontend parts use [React](https://react.dev/) and
framework whose frontend parts use [React](https://react.dev/) and
[Material UI](https://material-ui.com/), while the backend parts use
[Node.js](https://nodejs.org/) and the [Express](https://expressjs.com/)
framework.
docs/features/software-catalog/configuration.md
+10 -8
View File
@@ -181,28 +181,30 @@ this remote source, users cannot also register new entities with e.g. the
[catalog-import](https://github.com/backstage/backstage/tree/master/plugins/catalog-import)
plugin.
## Clean up orphaned entities
## Automatic removal of orphaned entities
In short, entities can become orphaned through multiple means, such as when a catalog-info YAML file is moved from one place to another in the version control system without updating the registration in the catalog. For safety reasons, the default behavior is to just tag the orphaned entities, and keep them around. You can read more about orphaned entities [here](life-of-an-entity.md#orphaning).
Entities can become orphaned through multiple means, such as when a catalog-info YAML file is moved from one place to another in the version control system without updating the registration in the catalog. The default behavior is to automatically remove orphaned entities. You can read more about orphaned entities [here](life-of-an-entity.md#orphaning).
However, if you do wish to automatically remove the orphaned entities, you can use the following configuration, and everything with an orphaned entity tag will be eventually deleted.
However, if you wish to keep orphaned entities, you can use the following configuration, and automatic cleanup will be disabled.
```yaml
catalog:
orphanStrategy: delete
orphanStrategy: keep
```
## Clean up entities from orphaned entity providers
## Automatic removal of entities from orphaned entity providers
By default, if an entity provider which has provided entities to the catalog, is no longer configured, then the entities remain in the catalog until they are manually unregistered.
By default, if an entity provider which has provided entities to the catalog is no longer configured, then the entities it provided will be automatically removed.
To remove these entities automatically, you can use the following configuration.
To keep these entities instead, you can use the following configuration.
```yaml
catalog:
orphanProviderStrategy: delete
orphanProviderStrategy: keep
```
If you have had providers installed in the past that ingested entities into the catalog that you want to keep, the recommendation is to add the provider back to the catalog. If you don’t want the provider to run, you can schedule it with a very large interval.
## Processing Interval
The [processing loop](./life-of-an-entity.md#processing) is
docs/features/software-catalog/life-of-an-entity.md
+6 -14
View File
@@ -254,8 +254,8 @@ either, it becomes _orphaned_. The end result is as follows:
the child entity.
- The child entity is _not_ removed from the catalog, but stays around until
explicitly deleted via the catalog API, implicitly if `orphanStrategy: delete`
configuration is set, or until it is "reclaimed" by the original parent
or another parent starting to reference it.
configuration is set (the default), or until it is "reclaimed" by the original
parent or another parent starting to reference it.
- The catalog page in Backstage for the child entity detects the new annotation
and informs users about the orphan status.
@@ -282,21 +282,13 @@ Orphaning can occur in several different scenarios.
> to inform the owner that something is wrong. But processing and other
> behaviors continue as usual.
The reason that the orphaning mechanism exists instead of having an eager
deletion triggered, is safety. Scenarios like these can happen purely by
accident, due to the asynchronous nature of the system and the fallible nature
of humans. In particular when external systems start consuming and relying on
the catalog, there could be substantial consequences to suddenly dropping
entities without explicit owner consent. The catalog therefore takes the stance
that entities that often were added by direct user action should also be deleted
only by direct user action.
However, if you want to delete orphaned entities automatically anyway, you can
enable the automated clean up with the following app-config option.
The default behavior of the catalog is to automatically remove orphaned
entities. However, if you want to keep them instead, you can disable the
automated cleanup with the following app-config option.
```
catalog:
orphanStrategy: delete
orphanStrategy: keep
```
## Implicit Deletion
docs/features/software-catalog/well-known-annotations.md
+40
View File
@@ -251,6 +251,46 @@ browser when viewing that user.
This annotation can be used on a [User entity](descriptor-format.md#kind-user)
to note that it originated from that user on GitHub.
### github.com/user-id
```yaml
# Example:
metadata:
annotations:
github.com/user-id: '123456'
```
The value of this annotation is the numeric user ID that identifies a user on
[GitHub](https://github.com) (either the public one, or a private GitHub
Enterprise installation) that is related to this entity. Unlike the username,
which can be changed by the user, the user ID is immutable.
This annotation can be used on a [User entity](descriptor-format.md#kind-user)
to note that it originated from that user on GitHub. It enables the
`userIdMatchingUserEntityAnnotation` sign-in resolver to match users by their
GitHub user ID during authentication.
### gitlab.com/user-id
```yaml
# Example:
metadata:
annotations:
gitlab.com/user-id: '123456'
```
The value of this annotation is the numeric user ID that identifies a user on
[GitLab](https://gitlab.com) (either the public one, or a private GitLab
installation) that is related to this entity. For self-hosted GitLab instances,
the annotation key will be `{integration-host}/user-id` where
`{integration-host}` is the hostname of your GitLab instance. Unlike the
username, which can be changed, the user ID is immutable.
This annotation can be used on a [User entity](descriptor-format.md#kind-user)
to note that it originated from that user on GitLab. It enables the
`userIdMatchingUserEntityAnnotation` sign-in resolver to match users by their
GitLab user ID during authentication.
### gocd.org/pipelines
```yaml
docs/features/software-templates/configuration.md
+59
View File
@@ -48,6 +48,65 @@ add the `repoVisibility` key within a software template:
repoVisibility: public # or 'internal' or 'private'
```
### Default Environment
The scaffolder supports a `defaultEnvironment` configuration that provides default parameters and secrets to all templates. This reduces template complexity and improves security by centralizing common values.
```yaml
scaffolder:
defaultEnvironment:
parameters:
region: eu-west-1
organizationName: acme-corp
defaultRegistry: registry.acme-corp.com
secrets:
AWS_ACCESS_KEY: ${AWS_ACCESS_KEY}
GITHUB_TOKEN: ${GITHUB_TOKEN}
DOCKER_REGISTRY_TOKEN: ${DOCKER_REGISTRY_TOKEN}
```
#### Default parameters
Default parameters are accessible via `${{ environment.parameters.* }}` in templates. Default parameters are isolated in their own context to avoid naming conflicts.
```yaml
parameters:
- title: Fill in some steps
required:
- organizationName
properties:
organizationName:
title: organizationName
type: string
description: Unique name of the organization
ui:autofocus: true
ui:options:
rows: 5
steps:
- id: deploy
name: Deploy Application
action: aws:deploy
input:
region: ${{ environment.parameters.region }} # Resolves to defaultEnvironment.parameters.region
organization: ${{ parameters.organizationName }} # Resolves to frontend input value
otherOrganization: ${{ environment.parameters.organizationName }} # Resolves to defaultEnvironment.parameters.organizationName
```
#### Secrets
Default secrets are resolved from environment variables and accessible via `${{ environment.secrets.* }}` in template actions. Secrets are only available during action execution, not in frontend forms.
```yaml
- id: deploy
name: Deploy with credentials
action: aws:deploy
input:
accessKey: ${{ environment.secrets.AWS_ACCESS_KEY }} # Resolves to defaultEnvironment.secrets.AWS_ACCESS_KEY
```
**Security Note:** Secrets are automatically masked in logs and are only available to backend actions, never exposed to the frontend.
## Disabling Docker in Docker situation (Optional)
Software templates use the `fetch:template` action by default, which requires no
docs/features/software-templates/ui-options-examples.md
+56
View File
@@ -468,3 +468,59 @@ repoUrl:
The supported `additionalScopes` values are `gerrit`, `github`, `gitlab`, `bitbucket`, and `azure`.
If you're also using the `RepoUrlPicker` field extension, you should simply duplicate this part from there.
## RepoOwnerPicker
The input props that can be specified under `ui:options` for the `RepoOwnerPicker` field extension.
### `host`
The SCM integration host that owners should be fetched from for autocompletion.
- Fetch owners from `github.com`
```yaml
repoUrl:
title: Repository Owner
type: string
ui:field: RepoOwnerPicker
ui:options:
host: github.com
```
### `excludedOwners`
List of owners that should be excluded from autocompletion.
- Exclude owner `owner_1` from autocompletion
```yaml
repoUrl:
title: Repository Owner
type: string
ui:field: RepoOwnerPicker
ui:options:
excludedOwners:
- owner_1
```
### `requestUserCredentials`
If defined will request user credentials to auth against the given SCM platform.
```yaml
repoUrl:
title: Repository Owner
type: string
ui:field: RepoOwnerPicker
ui:options:
requestUserCredentials:
secretsKey: USER_OAUTH_TOKEN
additionalScopes:
github:
- workflow:write
```
`secretsKey` is the key used within the template secrets context to store the credential and `additionalScopes` is any additional permission scopes to request.
The supported `additionalScopes` values are `gerrit`, `github`, `gitlab`, `bitbucket`, and `azure`.
docs/features/software-templates/writing-templates.md
+29
View File
@@ -555,6 +555,35 @@ The `RepoBranchPicker` is a custom field that we provide part of the
`plugin-scaffolder`. You can provide your own custom fields by
[writing your own Custom Field Extensions](./writing-custom-field-extensions.md)
### The Repository Owner Picker
Similar to the repository picker, there is a picker for owners to support autocompletion. A full example could look like this:
```yaml
- title: Choose an owner
required:
- repoOwner
properties:
repoOwner:
title: Repository Owner
type: string
ui:field: RepoOwnerPicker
ui:options:
host: github.com
excludedOwners:
- backstage
requestUserCredentials:
secretsKey: USER_OAUTH_TOKEN
```
Passing the `requestUserCredentials` and `host` properties is required for autocompletion to work. For more information regarding the `requestUserCredentials` object, please refer to the [Using the Users `oauth` token](#using-the-users-oauth-token) section under [The Repository Picker](#the-repository-picker).
For a list of all possible `ui:options` input props for `RepoOwnerPicker`, please visit [here](./ui-options-examples.md#repoownerpicker).
The `RepoOwnerPicker` is a custom field that we provide part of the
`plugin-scaffolder`. You can provide your own custom fields by
[writing your own Custom Field Extensions](./writing-custom-field-extensions.md)
### Accessing the signed-in users details
Sometimes when authoring templates, you'll want to access the user that is running the template, and get details from the profile or the users `Entity` in the Catalog.
docs/features/techdocs/using-cloud-storage.md
+44 -4
View File
@@ -172,15 +172,17 @@ TechDocs will publish documentation to this bucket and will fetch files from
here to serve documentation in Backstage. Note that the bucket names are
globally unique.
Set the config `techdocs.publisher.awsS3.bucketName` in your `app-config.yaml`
to the name of the bucket you just created.
Set the bucket name and region in your `app-config.yaml` to the name of the bucket you just created:
```yaml
techdocs:
publisher:
type: 'awsS3'
/* highlight-add-start */
awsS3:
bucketName: 'name-of-techdocs-storage-bucket'
region: 'us-east-1'
/* highlight-add-end */
```
**3. Create minimal AWS IAM policies to manage TechDocs**
@@ -266,7 +268,7 @@ environment automatically by defining appropriate IAM role with access to the
bucket. Read more in the
[official AWS documentation for using IAM roles](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html#use-roles).
**4b. Authentication using app-config.yaml**
**4b. Authentication using app-config.yaml via aws.accounts**
AWS credentials and region can be provided to the AWS SDK via `app-config.yaml`.
If the configs below are present, they will be used over existing `AWS_*`
@@ -290,7 +292,45 @@ aws:
Refer to the
[official AWS documentation for obtaining the credentials](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/setting-credentials-node.html).
**4c. Authentication using an assumed role** Users with multiple AWS accounts
**4c. Authentication using app-config.yaml via integrations.awsS3**
If you already have an [AWS S3 integration](../../integrations/aws-s3/locations.md), you can use it to authenticate with AWS S3:
```yaml
techdocs:
publisher:
type: 'awsS3'
awsS3:
bucketName: 'name-of-techdocs-storage-bucket'
region: 'eu-west-1'
integrations:
awsS3:
- accessKeyId: ${AWS_ACCESS_KEY_ID}
secretAccessKey: ${AWS_SECRET_ACCESS_KEY}
```
This will use the credentials from the integration to authenticate with AWS S3 and it does not require any additional configuration in the `app-config.yaml`. However, **if you have multiple S3 integrations**, you **must** specify the target integration by setting the `accessKeyId` in the `techdocs.publisher.awsS3.credentials` config:
```yaml
techdocs:
publisher:
type: 'awsS3'
awsS3:
bucketName: 'name-of-techdocs-storage-bucket'
region: 'eu-west-1'
/* highlight-add-start */
credentials:
accessKeyId: ${AWS_ACCESS_KEY_ID_1}
/* highlight-add-end */
integrations:
awsS3:
- accessKeyId: ${AWS_ACCESS_KEY_ID_1}
secretAccessKey: ${AWS_SECRET_ACCESS_KEY_1}
- accessKeyId: ${AWS_ACCESS_KEY_ID_2}
secretAccessKey: ${AWS_SECRET_ACCESS_KEY_2}
```
**4d. Authentication using an assumed role** Users with multiple AWS accounts
may want to use a role for S3 storage that is in a different AWS account. Using
the `roleArn` parameter as seen below, you can instruct the TechDocs publisher
to assume a role before accessing S3.
docs/frontend-system/architecture/20-extensions.md
+66
View File
@@ -352,3 +352,69 @@ const extension = createExtension({
},
});
```
## Relative attachment points
When creating an extension or an [extension blueprint](./23-extension-blueprints.md) you can specify an attachment point that is relative to the current plugin. This is particularly useful for groups of blueprints that are part of a common hierarchy, with extensions from one blueprint attaching to extensions from the other blueprint. For example, the following pair of extension definitions could be installed multiple times in different plugins, each creating their own hierarchy:
```tsx
// Parent extension with a fixed attachment point
const parentExtension = createExtension({
kind: 'section',
attachTo: [{ id: 'app/some-fixed-extension', input: 'children' }],
inputs: {
content: createExtensionInput([coreExtensionData.reactElement], {
singleton: true,
}),
},
output: [coreExtensionData.reactElement],
factory({ inputs }) {
return [
coreExtensionData.reactElement(
<section>
<h1>Section Title</h1>
{inputs.content.get(coreExtensionData.reactElement)}
</section>,
),
];
},
});
// Child extension with a relative attachment point
const childExtension = createExtension({
kind: 'section-content',
attachTo: [{ relative: { kind: 'section' }, input: 'content' }],
output: [coreExtensionData.reactElement],
factory() {
return [coreExtensionData.reactElement(<p>Section Content</p>)];
},
});
```
## Extension input references
Building on the relative attachment point concept, you can also reference extension inputs directly via the `inputs` property of an extension definition. This provides a more convenient and type-safe way to attach child extensions, especially when using blueprints that provide a nested hierarchy of extensions.
Extension inputs references are always relative, this means that they can only be used for referencing extensions within the same plugin.
Each extension definition exposes an `inputs` property that contains references to all of its defined inputs. These references can be passed directly to the `attachTo` option when creating child extensions:
```tsx
const parent = createExtension({
inputs: {
children: createExtensionInput([coreExtensionData.reactElement]),
},
// other options...
});
// Create a child extension that attaches to the parent's input
const child = createExtension({
attachTo: page.inputs.children, // Direct reference to the input
output: [coreExtensionData.reactElement], // Outputs are verified against the parent input
// other options...
});
```
These references are a type-safe way to attach child extensions, it both ensures that the parent input is present, as well as the child providing the required data for the parent.
Under the hood, input references are resolved in the same way as relative attachment points, using the extension's kind, namespace, and name to construct the final attachment target.
docs/frontend-system/building-apps/01-index.md
+3 -3
View File
@@ -14,16 +14,16 @@ A Backstage App is a monorepo setup that includes everything you need to run Bac
To create a new Backstage app we recommend using the `@backstage/create-app` command line, and the easiest way to run this package is with `npx`:
:::note
The create-app CLI requires Node.js Active LTS Release.
The create-app CLI requires Node.js Active LTS Release, see the [prerequisites documentation](../../getting-started/index.md) for all the details.
:::
```sh
# The command bellow creates a Backstage App inside the current folder.
# The name of the app-folder is the name that was provided when prompted.
npx @backstage/create-app@latest
npx @backstage/create-app@latest --next
```
The created-app is currently templated for legacy frontend system applications, so the app wiring code it creates needs to be migrated, see [the app instance](#the-app-instance) section for an example.
Using the `--next` flag will result in a Backstage app using the New Frontend System which will be further explained in the sections below.
## The app instance
docs/frontend-system/building-apps/08-migrating.md
+31 -84
View File
@@ -9,7 +9,7 @@ description: How to migrate existing apps to the new frontend system
This section describes how to migrate an existing Backstage app package to use the new frontend system. The app package is typically found at `packages/app` in your project and is responsible for wiring together the Backstage frontend application.
> **Who is this for?**
> **Who is this for?**
> This guide is intended for maintainers of Backstage app packages (`packages/app`) who want to upgrade from the legacy frontend system to the new extension-based architecture.
> **Prerequisites:**
@@ -22,10 +22,10 @@ This section describes how to migrate an existing Backstage app package to use t
We recommend a **two-phase migration process** to ensure a smooth and manageable transition:
- **Phase 1: Minimal Changes for Hybrid Configuration**
- **Phase 1: Minimal Changes for Hybrid Configuration**
In this phase, you make the smallest set of changes necessary to enable your app to run in a hybrid mode. This allows you to start using the new frontend system while still relying on compatibility helpers and legacy code. The goal is to unblock your migration quickly, so you can benefit from the new system without a full rewrite.
- **Phase 2: Complete Transition to the New Frontend System**
- **Phase 2: Complete Transition to the New Frontend System**
After your app is running in hybrid mode, you can gradually refactor your codebase to remove legacy code and compatibility helpers. This phase focuses on fully adopting the new frontend architecture, ensuring your codebase is clean, maintainable, and takes full advantage of the new features.
:::warning
@@ -157,36 +157,6 @@ const app = createApp({
});
```
If you were binding routes from a legacy `createApp`, you will need to use the `convertLegacyRouteRefs` and/or `convertLegacyRouteRef` to convert the routes to be compatible with the new system.
For example, if both the `catalogPlugin` and `scaffolderPlugin` are legacy plugins, you can bind their routes like this:
```ts
import { createApp } from '@backstage/frontend-defaults';
import {
// ...
convertLegacyRouteRefs,
convertLegacyRouteRef,
} from '@backstage/core-compat-api';
// Ommitting converted options changes
//...
const app = createApp({
features: [
// ...
convertedOptionsModule,
],
// highlight-add-start
bindRoutes({ bind }) {
bind(convertLegacyRouteRefs(catalogPlugin.externalRoutes), {
createComponent: convertLegacyRouteRef(scaffolderPlugin.routes.root),
});
},
// highlight-add-end
});
```
### 3) Fixing the `app.createRoot` call
The `app.createRoot(...)` no longer accepts any arguments. This represents a fundamental change that the new frontend system introduces. In the old system the app element tree that you passed to `app.createRoot(...)` was the primary way that you installed and configured plugins and features in your app. In the new system this is instead replaced by extensions that are wired together into an extension tree. Much more responsibility has now been shifted to plugins, for example you no longer have to manually provide the route path for each plugin page, but instead only configure it if you want to override the default. For more information on how the new system works, see the [architecture](../architecture/00-index.md) section.
@@ -474,7 +444,7 @@ const app = createApp({
Can be converted to the following extension:
```tsx
import { SignInPageBlueprint } from '@backstage/frontend-plugin-api';
import { SignInPageBlueprint } from '@backstage/plugin-app-react';
const signInPage = SignInPageBlueprint.make({
params: {
@@ -522,7 +492,7 @@ const app = createApp({
Can be converted to the following extension:
```tsx
import { ThemeBlueprint } from '@backstage/frontend-plugin-api';
import { ThemeBlueprint } from '@backstage/plugin-app-react';
const customLightThemeExtension = ThemeBlueprint.make({
name: 'custom-light',
@@ -565,7 +535,7 @@ const app = createApp({
Icons are now installed as extensions, using the `IconBundleBlueprint` to make new instances which can be added to the app.
```ts
import { IconBundleBlueprint } from '@backstage/frontend-plugin-api';
import { IconBundleBlueprint } from '@backstage/plugin-app-react';
const exampleIconBundle = IconBundleBlueprint.make({
name: 'example-bundle',
@@ -590,21 +560,6 @@ const app = createApp({
Route bindings can still be done using this option, but you now also have the ability to bind routes using static configuration instead. See the section on [binding routes](../architecture/36-routes.md#binding-external-route-references) for more information.
Note that if you are binding routes from a legacy plugin that was converted using `convertLegacyAppRoot`, you will need to use the `convertLegacyRouteRefs` and/or `convertLegacyRouteRef` to convert the routes to be compatible with the new system.
For example, if both the `catalogPlugin` and `scaffolderPlugin` are legacy plugins, you can bind their routes like this:
```ts
const app = createApp({
features: convertLegacyAppRoot(...),
bindRoutes({ bind }) {
bind(convertLegacyRouteRefs(catalogPlugin.externalRoutes), {
createComponent: convertLegacyRouteRef(scaffolderPlugin.routes.root),
});
},
});
```
#### `__experimentalTranslations`
Translations are now installed as extensions, created using `TranslationBlueprint`.
@@ -631,10 +586,8 @@ Can be converted to the following extension:
```tsx
import { catalogTranslationRef } from '@backstage/plugin-catalog/alpha';
import {
createTranslationMessages,
TranslationBlueprint,
} from '@backstage/frontend-plugin-api';
import { createTranslationMessages } from '@backstage/frontend-plugin-api';
import { TranslationBlueprint } from '@backstage/plugin-app-react';
const catalogTranslations = TranslationBlueprint.make({
name: 'catalog-overrides',
@@ -707,7 +660,7 @@ const convertedRootFeatures = convertLegacyAppRoot(
);
```
Any app root wrapper needs to be migrated to be an extension, created using `AppRootWrapperBlueprint`. Note that if you have multiple wrappers they must be completely independent of each other, i.e. the order in which they the appear in the React tree should not matter. If that is not the case then you should group them into a single wrapper.
Any app root wrapper needs to be migrated to be an extension, created using `AppRootWrapperBlueprint` from `@backstage/plugin-app-react`. Note that if you have multiple wrappers they must be completely independent of each other, i.e. the order in which they the appear in the React tree should not matter. If that is not the case then you should group them into a single wrapper.
Here is an example converting the `CustomAppBarrier` into extension:
@@ -721,8 +674,6 @@ createApp({
AppRootWrapperBlueprint.make({
name: 'custom-app-barrier',
params: {
// Whenever your component uses legacy core packages, wrap it with "compatWrapper"
// e.g. props => compatWrapper(<CustomAppBarrier {...props} />)
Component: CustomAppBarrier,
},
}),
@@ -749,37 +700,33 @@ export const navModule = createFrontendModule({
});
```
Then in the actual implementation for the `SidebarContent` extension, you can provide something like the following, where the component that is passed to the `compatWrapper` is the entire `Sidebar` component from your `Root` component.
The `compatWrapper` is there to ensure that any legacy plugins using things like `useRouteRef` work well in the new system, so if you run into some errors which look like compatibility issues, make sure that this wrapper is used in the relevant places.
Then in the actual implementation for the `SidebarContent` extension, you can provide something like the following, where you implement the entire `Sidebar` component.
```tsx title="in packages/app/src/modules/nav/Sidebar.tsx"
import { compatWrapper } from '@backstage/core-compat-api';
import { NavContentBlueprint } from '@backstage/frontend-plugin-api';
import { NavContentBlueprint } from '@backstage/plugin-app-react';
export const SidebarContent = NavContentBlueprint.make({
params: {
component: ({ items }) =>
compatWrapper(
<Sidebar>
<SidebarLogo />
<SidebarGroup label="Search" icon={<SearchIcon />} to="/search">
<SidebarSearchModal />
</SidebarGroup>
<SidebarDivider />
<SidebarGroup label="Menu" icon={<MenuIcon />}>
...
</SidebarGroup>
<SidebarGroup label="Plugins">
<SidebarScrollWrapper>
{/* Items in this group will be scrollable if they run out of space */}
{items.map((item, index) => (
<SidebarItem {...item} key={index} />
))}
</SidebarScrollWrapper>
</SidebarGroup>
</Sidebar>,
),
component: ({ items }) => (
<Sidebar>
<SidebarLogo />
<SidebarGroup label="Search" icon={<SearchIcon />} to="/search">
<SidebarSearchModal />
</SidebarGroup>
<SidebarDivider />
<SidebarGroup label="Menu" icon={<MenuIcon />}>
...
</SidebarGroup>
<SidebarGroup label="Plugins">
<SidebarScrollWrapper>
{/* Items in this group will be scrollable if they run out of space */}
{items.map((item, index) => (
<SidebarItem {...item} key={index} />
))}
</SidebarScrollWrapper>
</SidebarGroup>
</Sidebar>
),
},
});
```
docs/frontend-system/building-plugins/01-index.md
+2 -2
View File
@@ -124,7 +124,7 @@ export interface ExampleApi {
}
export const exampleApiRef = createApiRef<ExampleApi>({
id: 'plugin.example',
id: 'plugin.example.api',
});
export class DefaultExampleApi implements ExampleApi {
@@ -220,6 +220,6 @@ export const examplePlugin = createFrontendPlugin({
});
```
The `ExampleEntityContent` itself is again a regular React component where you can implement any functionality you want. To access the entity that the content is being rendered for, you can use the `useEntity` hook from `@backstage/plugin-catalog-react`. You can see a full list of APIs provided by the catalog React library in [the API reference](../../reference/plugin-catalog-react.md).
The `ExampleEntityContent` itself is again a regular React component where you can implement any functionality you want. To access the entity that the content is being rendered for, you can use the `useEntity` hook from `@backstage/plugin-catalog-react`. You can see a full list of APIs provided by the catalog React library in [the API reference](https://backstage.io/api/stable/modules/_backstage_plugin-catalog-react.index.html).
For a more complete list of the different kinds of extensions that you can create for your plugin, see the [extension blueprints](./03-common-extension-blueprints.md) section.
docs/frontend-system/building-plugins/03-common-extension-blueprints.md
+24 -8
View File
@@ -11,38 +11,54 @@ This section covers many of the [extension blueprints](../architecture/23-extens
These are the [extension blueprints](../architecture/23-extension-blueprints.md) provided by the Backstage frontend framework itself.
### Api - [Reference](../../reference/frontend-plugin-api.apiblueprint.md)
### Api - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.ApiBlueprint.html)
An API extension is used to add or override [Utility API factories](../utility-apis/01-index.md) in the app. They are commonly used by plugins for both internal and shared APIs. There are also many built-in Api extensions provided by the framework that you are able to override.
### NavItem - [Reference](../../reference/frontend-plugin-api.navitemblueprint.md)
### NavItem - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.NavItemBlueprint.html)
Navigation item extensions are used to provide menu items that link to different parts of the app. By default nav items are attached to the app nav extension, which by default is rendered as the left sidebar in the app.
### Page - [Reference](../../reference/frontend-plugin-api.pageblueprint.md)
### Page - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.PageBlueprint.html)
Page extensions provide content for a particular route in the app. By default pages are attached to the app routes extensions, which renders the root routes.
### SignInPage - [Reference](../../reference/frontend-plugin-api.signinpageblueprint.md)
## Extension blueprints in `@backstage/frontend-plugin-api/alpha`
### Plugin Wrapper - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.packages-frontend-plugin-api_src_alpha.PluginWrapperBlueprint.html)
Plugin wrappers allow you to install components that will wrap all elements rendered as part of a plugin. This can be useful if you need to add a global provider, for example for a query client. The provided wrapper will be rendered as separate elements for each wrapped plugin element, so be sure to use a central store like a [Utility API](../utility-apis/01-index.md) if you want to share state between wrapper instances.
## Extension blueprints in `@backstage/plugin-app-react`
### SignInPage - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.SignInPageBlueprint.html)
Sign-in page extension have a single purpose - to implement a custom sign-in page. They are always attached to the app root extension and are rendered before the rest of the app until the user is signed in.
### SwappableComponent - [Reference](../../reference/frontend-plugin-api.swappablecomponentblueprint.md)
### SwappableComponent - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.SwappableComponentBlueprint.html)
Swappable Components are extensions that are used to replace the implementations of components in the app and plugins.
### Theme - [Reference](../../reference/frontend-plugin-api.themeblueprint.md)
### Theme - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.ThemeBlueprint.html)
Theme extensions provide custom themes for the app. They are always attached to the app extension and you can have any number of themes extensions installed in an app at once, letting the user choose which theme to use.
### Icons - [Reference](../../reference/frontend-plugin-api.iconbundleblueprint.md)
### Icons - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.IconBundleBlueprint.html)
Icon bundle extensions provide the ability to replace or provide new icons to the app. You can use the above blueprint to make new extension instances which can be installed into the app.
### Translation - [Reference](../../reference/frontend-plugin-api.translationblueprint.md)
### Translation - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.TranslationBlueprint.html)
Translation extension provide custom translation messages for the app. They can be used both to override the default english messages to custom ones, as well as provide translations for additional languages.
### NavContent - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.NavContentBlueprint.html)
Nav content extensions allow you to replace the entire navbar with your own component. They are always attached to the app nav extension.
### Router - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.RouterBlueprint.html)
Router extensions allow you to replace the router component used by the app. They are always attached to the app root extension.
## Extension blueprints in `@backstage/plugin-catalog-react/alpha`
These are the [extension blueprints](../architecture/23-extension-blueprints.md) provided by the Catalog plugin.
docs/frontend-system/building-plugins/05-migrating.md
+7 -20
View File
@@ -38,7 +38,6 @@ In order to migrate the actual definition of the plugin you need to recreate the
```ts title="my-plugin/src/alpha.tsx"
import { createFrontendPlugin } from '@backstage/frontend-plugin-api';
import { convertLegacyRouteRefs } from '@backstage/core-compat-api';
export default createFrontendPlugin({
// The plugin ID is now provided as `pluginId` instead of `id`
@@ -47,15 +46,12 @@ In order to migrate the actual definition of the plugin you need to recreate the
// bind all the extensions to the plugin
/* highlight-next-line */
extensions: [/* APIs will go here, but don't worry about those yet */],
// convert old route refs to the new system
/* highlight-next-line */
routes: convertLegacyRouteRefs({
routes: {
...
}),
/* highlight-next-line */
externalRoutes: convertLegacyRouteRefs({
},
externalRoutes: {
...
}),
},
});
```
@@ -110,25 +106,16 @@ it can be migrated as the following, keeping in mind that you may need to switch
```tsx
import { PageBlueprint } from '@backstage/frontend-plugin-api';
import {
compatWrapper,
convertLegacyRouteRef,
} from '@backstage/core-compat-api';
const fooPage = PageBlueprint.make({
params: {
// This is the path that was previously defined in the app code.
// It's labelled as the default one because it can be changed via configuration.
path: '/foo',
// You can reuse the existing routeRef by wrapping it with convertLegacyRouteRef.
routeRef: convertLegacyRouteRef(rootRouteRef),
// You can reuse the existing routeRef.
routeRef: rootRouteRef,
// these inputs usually match the props required by the component.
loader: () =>
import('./components/').then(m =>
// The compatWrapper utility allows you to keep using @backstage/core-plugin-api in the
// implementation of the component and switch to @backstage/frontend-plugin-api later.
compatWrapper(<m.FooPage />),
),
loader: () => import('./components/').then(m => <m.FooPage />),
},
});
```
docs/frontend-system/building-plugins/06-swappable-components.md
+2 -5
View File
@@ -52,11 +52,8 @@ In order to override a Swappable Component, you need to create a `SwappableCompo
There are two different ways to add extensions to the `app` plugin, both are documented below in an example of overriding the `Progress` Swappable Component.
```tsx title="in packages/app/src/App.tsx"
import {
Progress,
SwappableComponentBlueprint,
createFrontendModule,
} from '@backstage/frontend-plugin-api';
import { Progress, createFrontendModule } from '@backstage/frontend-plugin-api';
import { SwappableComponentBlueprint } from '@backstage/plugin-app-react';
import { MyCustomProgress } from './CustomProgress';
import { createApp } from '@backstage/frontend-defaults';
import appPlugin from '@backstage/plugin-app';
docs/frontend-system/utility-apis/02-creating.md
+3
View File
@@ -36,6 +36,9 @@ export const workApiRef = createApiRef<WorkApi>({
Both of these are properly exported publicly from the package, so that consumers can reach them.
The frontend system infers the owning plugin for an API from the `ApiRef` id, so
use the pattern `plugin.<plugin-id>.*` to make ownership explicit. This ensures that other plugins can't mistakenly override your API.
## Providing an extension through your plugin
The plugin itself now wants to provide this API and its default implementation, in the form of an API extension. Doing so means that when users install the Example plugin, an instance of the Work utility API will also be automatically available in their apps - both to the Example plugin itself, and to others. We do this in the main plugin package, not the `-react` package.
docs/frontend-system/utility-apis/04-configuring.md
+2
View File
@@ -36,6 +36,8 @@ Well written input-enabled extension often have extension creator functions that
Like with other extension types, you replace Utility APIs with your own custom implementation using [extension overrides](../architecture/25-extension-overrides.md).
Note that it is only possible to override a Utility API using a module for the plugin that originally provided the API. Attempting to override an API using a different plugin or module for a different plugin will result in a conflict error.
```tsx title="in your app"
/* highlight-add-start */
import { createFrontendModule } from '@backstage/frontend-plugin-api';
docs/getting-started/config/database.md
+3 -3
View File
@@ -129,13 +129,13 @@ You can run Postgres in a Docker container, this is great for local development
First we need to pull down the container image, we'll use Postgres 17, check out the [Postgres Version Policy](../../overview/versioning-policy.md#postgresql-releases) to learn which versions are supported.
```shell
docker pull postgres:17.0-bookworm
docker pull postgres:17.0-trixie
```
Then we just need to start up the container.
```shell
docker run -d --name postgres --restart=always -p 5432:5432 -e POSTGRES_PASSWORD=<secret> postgres:17.0-bookworm
docker run -d --name postgres --restart=always -p 5432:5432 -e POSTGRES_PASSWORD=<secret> postgres:17.0-trixie
```
This will run Postgres in the background for you, but remember to start it up again when you reboot your system.
@@ -149,7 +149,7 @@ version: '4'
services:
postgres:
image: postgres:17.0-bookworm
image: postgres:17.0-trixie
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: <secret>
docs/getting-started/index.md
+95 -79
View File
@@ -1,8 +1,8 @@
---
id: index
title: Creating your Backstage App
sidebar_label: Introduction
description: How to install Backstage for your own use.
title: Standalone Installation
sidebar_label: Standalone Installation
description: How to create and run a Standalone Backstage.
---
Audience: Developers and Admins
@@ -11,11 +11,11 @@ Audience: Developers and Admins
It is not required, although recommended to have a basic understanding of [Yarn](https://www.pluralsight.com/guides/yarn-a-package-manager-for-node-js) and [npm](https://docs.npmjs.com/about-npm) before starting this guide.
:::
## Summary
## Overview
This guide walks through how to get started creating your very own Backstage customizable app. This is the first step in evaluating, developing on, or demoing Backstage.
This guide walks through how to create your own Backstage customizable app. This is the first step in evaluating, developing on, or demoing Backstage.
By the end of this guide, you will have a standalone Backstage installation running locally with a `SQLite` database and demo content. To be clear, this is not a production-ready installation, and it does not contain information specific to your organization.
By the end of this guide, you will have a standalone Backstage installation running locally with an in-memory `SQLite` database and demo content. To be clear, this is not a production-ready installation, and it does not contain information specific to your organization until you set up integrations with your specific data sources!
:::note Contributors
@@ -23,46 +23,9 @@ If you are planning to contribute a new feature or bug fix to the Backstage proj
:::
## Prerequisites
The instructions make use of `npx`. `npx` is a tool that comes preinstalled with Node.js and lets you run commands straight from `npm` or other registries.
This guide also assumes a basic understanding of working on a Linux based operating system and have some experience with the terminal, specifically, these commands: `npm`, `yarn`.
- Access to a Unix-based operating system, such as Linux, macOS or
[Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/)
- A GNU-like build environment available at the command line.
For example, on Debian/Ubuntu you will want to have the `make` and `build-essential` packages installed.
On macOS, you will want to run `xcode-select --install` to get the XCode command line build tooling in place.
- An account with elevated rights to install the dependencies
- `curl` or `wget` installed
- Node.js [Active LTS Release](../overview/versioning-policy.md#nodejs-releases) installed using one of these
methods:
- Using `nvm` (recommended)
- [Installing nvm](https://github.com/nvm-sh/nvm#install--update-script)
- [Install and change Node version with nvm](https://nodejs.org/en/download/package-manager/#nvm)
- Node 20 is a good starting point, this can be installed using `nvm install lts/iron`
- [Binary Download](https://nodejs.org/en/download/)
- [Package manager](https://nodejs.org/en/download/package-manager/)
- [Using NodeSource packages](https://github.com/nodesource/distributions/blob/master/README.md)
- `yarn` [Installation](https://yarnpkg.com/getting-started/install)
- Backstage currently uses Yarn 4.4.1, once you've ran `corepack enable` you'll want to then run `yarn set version 4.4.1`
- `docker` [installation](https://docs.docker.com/engine/install/)
- `git` [installation](https://github.com/git-guides/install-git)
- If the system is not directly accessible over your network the following ports
need to be opened: 3000, 7007. This is quite uncommon, unless you're installing in a container, VM or remote system.
## 1. Create your Backstage App
:::caution
The Backstage app we'll be creating will only have demo data until we set up integrations with your specific data sources!
:::
To install the Backstage Standalone app, we will make use of `npx`. `npx` is a tool that comes preinstalled with Node.js and lets you run commands straight from `npm` or other registries. Before we run the command, let's discuss what it does.
This command will create a new directory with a Backstage app inside. The wizard will ask you for the name of the app. This name will be created as subdirectory in your current working directory.
![create app](../assets/getting-started/create-app-output.png)
This command creates a new directory with a Backstage app inside. The wizard will ask you for the name of the app. This name will be created as a subdirectory in your current working directory.
Inside that directory, it will generate all the files and folder structure
needed for you to run your app.
@@ -100,65 +63,122 @@ app
and [TechDocs](https://backstage.io/docs/features/techdocs/)
amongst other things.
Now, that we know what it does, let's run it!
## Prerequisites
```bash
npx @backstage/create-app@latest
```
This guide also assumes a basic understanding of working on a Linux based operating system and have some experience with the terminal, specifically, these commands: `npm`, `yarn`.
- A minimum of 20 GB disk space to run the standalone Backstage application with demo data. NOTE: As you add more modules and plugins to an installation, the disk space requirements will increase, accordingly.
- A minimum of 6 GB memory.
- Access to a Unix-based operating system, such as Linux, macOS or
[Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/). The Linux version must support the required Node.js version.
- A GNU-like build environment available at the command line.
For example, on Debian/Ubuntu you will want to have the `make` and `build-essential` packages installed.
On macOS, you will want to run `xcode-select --install` to get the XCode command line build tooling in place.
- An account with elevated rights to install the dependencies
- `curl` or `wget` installed
- Node.js [Active LTS Release](../overview/versioning-policy.md#nodejs-releases) installed using one of these
methods:
- Using `nvm` (recommended)
- [Installing nvm](https://github.com/nvm-sh/nvm#install--update-script)
- [Install and change Node version with nvm](https://nodejs.org/en/download/package-manager/#nvm)
- Node 24 is a good starting point, this can be installed using `nvm install lts/krypton`
- [Binary Download](https://nodejs.org/en/download/)
- [Package manager](https://nodejs.org/en/download/package-manager/)
- [Using NodeSource packages](https://github.com/nodesource/distributions/blob/master/README.md)
- Install the `isolated-vm` module, following their [requirements section](https://github.com/laverdet/isolated-vm#requirements).
- `yarn` [Installation](https://yarnpkg.com/getting-started/install)
- Backstage currently uses Yarn 4.4.1, once you've ran `corepack enable` you'll want to then run `yarn set version 4.4.1`
- `docker` [installation](https://docs.docker.com/engine/install/)
- `git` [installation](https://github.com/git-guides/install-git)
- If the system is not directly accessible over your network the following ports
need to be opened: 3000, 7007. This is quite uncommon, unless you're installing in a container, VM or remote system.
## Creating and running a Backstage application
This may take a few minutes to fully install everything. Don't stress if the loading seems to be spinning nonstop, there's a lot going on in the background.
:::note
To create the application:
If this fails on the `yarn install` step, it's likely that you will need to install some additional dependencies which are used to configure `isolated-vm`. You can find out more in their [requirements section](https://github.com/laverdet/isolated-vm#requirements), and then run `yarn install` manually again after you've completed those steps.
1. Type the following command to install the Backstage application.
:::
```bash
npx @backstage/create-app@latest
```
## 2. Run the Backstage app
2. If this is the first time that you are installing a Backstage application on this device, the following question is displayed. Enter `y` and select `Enter` to proceed with the installation.
```
Need to install the following packages:
@backstage/create-app@0.7.4
ok to proceed? (y)
```
3. Enter the name for your application and select `Enter`. This is the root directory of your application. In this example, the name is set to `my-backstage-app`.
![create app](../assets/getting-started/create-app-output.png)
Your Backstage app is fully installed and ready to be run! Now that the installation is complete, you can go to the application directory and start the app using the `yarn start` command. The `yarn start` command will run both the frontend and backend as separate processes (named `[0]` and `[1]`) in the same window.
```bash
cd my-backstage-app # your app name
yarn start
To run the application:
1. Change to the root directory of your Backstage app. This is the same as the name of your application that you provided during the installation. In this example, it is `my-backstage-app`.
```bash
cd my-backstage-app
```
2. Start the Backstage application.
```bash
yarn start
```
As the frontend and backend are starting, you will see output similar to the following. The output shows that the app and backend are starting up with the configuration coming from `app-config.yaml`. You will see the plugins being initialized, and authorization and permissions being setup. In addition you will see a series of REST API calls for those plugins that use a service backend, such as the service catalog.
```
Starting app, backend
Loaded config from app-config.yaml
.
.
2025-10-15T12:26:41.564Z backstage info Plugin initialization started: 'app', 'proxy', 'scaffolder', 'techdocs', 'auth', 'catalog', 'permission', 'search', 'kubernetes', 'notifications', 'signals' type="initialization"
Rspack compiled successfully
.
.
2025-10-15T15:17:21.130Z auth info Created new signing key eec1a9e4-4395-4698-9a9f-f1b5cbcf152b component="token-factory"
2025-10-15T15:17:21.139Z auth info Issuing token for user:development/guest, with entities user:development/guest component="token-factory"
2025-10-15T15:17:21.223Z rootHttpRouter info [2025-10-15T15:17:21.223Z] "GET /api/auth/guest/refresh HTTP/1.1" 200 802 "http://localhost:3000/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0" type="incomingRequest" date="2025-10-15T15:17:21.223Z" method="GET" url="/api/auth/guest/refresh" status=200 httpVersion="1.1" userAgent="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0" contentLength=802 referrer="http://localhost:3000/"
.
.
2025-10-15T15:17:24.051Z rootHttpRouter info [2025-10-15T15:17:24.051Z] "GET /api/catalog/entities?fields=metadata,kind,spec.profile&filter=kind%3Dgroup%2Crelations.hasMember%3Duser%3Adevelopment%2Fguest HTTP/1.1" 304 0 "http://localhost:3000/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0" type="incomingRequest" date="2025-10-15T15:17:24.051Z" method="GET" url="/api/catalog/entities?fields=metadata,kind,spec.profile&filter=kind%3Dgroup%2Crelations.hasMember%3Duser%3Adevelopment%2Fguest" status=304 httpVersion="1.1" userAgent="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0" referrer="http://localhost:3000/"
.
.
```
![Screenshot of the command output, with the message web pack compiled successfully](../assets/getting-started/startup.png)
Once the Backstage UI is displayed, you can start exploring the demo immediately.
Here again, there's a small wait for the frontend to start up. Once the frontend is built, your browser window should automatically open.
:::tip Browser window didn't open with yarn start
:::tip Browser window didn't open
When you see the message `[0] webpack compiled successfully`, you can navigate directly to `http://localhost:3000` to see your Backstage app.
When you see the message `Rspack compiled successfully`, you can navigate directly to `http://localhost:3000` to see your Backstage app.
:::
You can start exploring the demo immediately.
![Screenshot of the Backstage portal.](../assets/getting-started/portal.png)
## Recap
This tutorial walked through how to deploy Backstage using the `npx @backstage/create-app@latest` command. That command created a new directory that holds your new Backstage app. That app is currently only configured for development purposes, as it is using an in-memory database and contains demo data.
## Next steps
Choose the correct next steps for your user role, if you're likely to be deploying and managing a Backstage instance for your organization, look through the [Admin](#admin) section. If you're likely to be developing on/for Backstage, take a look through the [Developer](#developer) section.
### Admin
- Deploying to production
- Configuring Backstage
- [Setting up authentication](./config/authentication.md)
- [Configuring a database](./config/database.md)
- [Deploying with Docker](../deployment/docker.md)
- [Deploying with Kubernetes](../deployment/k8s.md)
- Configuring Backstage
- [Adding plugins](./configure-app-with-plugins.md)
- [Customizing Your App's UI](../conf/user-interface/index.md)
- [Populating the homepage](./homepage.md)
- Deploying to production
- [Deploying with Docker](../deployment/docker.md)
- [Deploying with Kubernetes](../deployment/k8s.md)
### Developer
@@ -171,8 +191,4 @@ Share your experiences, comments, or suggestions with us:
[on discord](https://discord.gg/backstage-687207715902193673), file issues for any
[feature](https://github.com/backstage/backstage/issues/new?labels=help+wanted&template=feature_template.md)
or
[plugin suggestions](https://github.com/backstage/community-plugins/issues/new/choose),
or
[bugs](https://github.com/backstage/backstage/issues/new?labels=bug&template=bug_template.md)
you have, and feel free to
[contribute](https://github.com/backstage/backstage/blob/master/CONTRIBUTING.md)!
[plugin suggestions](https://github.com/backstage/community-plugins/issues/new/choose)
docs/integrations/bitbucketCloud/discovery.md
+4
View File
@@ -54,6 +54,8 @@ You need to decide how you want to receive events from external sources like
- [via HTTP endpoint](https://github.com/backstage/backstage/tree/master/plugins/events-backend/README.md)
- [via an AWS SQS queue](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md)
- [via Google Pub/Sub](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-google-pubsub/README.md)
- [via a Kafka topic](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-kafka/README.md)
Further documentation:
@@ -72,6 +74,8 @@ Additionally, you need to decide how you want to receive events from external so
- [via HTTP endpoint](https://github.com/backstage/backstage/tree/master/plugins/events-backend/README.md)
- [via an AWS SQS queue](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md)
- [via Google Pub/Sub](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-google-pubsub/README.md)
- [via a Kafka topic](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-kafka/README.md)
Set up your provider
docs/integrations/bitbucketCloud/locations.md
+26 -3
View File
@@ -14,11 +14,31 @@ plugin.
## Configuration
API token usage example (recommended):
```yaml
integrations:
bitbucketCloud:
- username: ${BITBUCKET_CLOUD_USERNAME}
appPassword: ${BITBUCKET_CLOUD_PASSWORD}
- username: user@domain.com # username -> user email
token: my-token
```
Legacy:
```yaml
integrations:
bitbucketCloud:
- username: username
appPassword: my-password
```
OAuth 2.0 client credentials flow:
```yaml
integrations:
bitbucketCloud:
- clientId: client-id
clientSecret: client-secret
```
:::note Note
@@ -30,7 +50,7 @@ convenience, so you only need to list it if you want to supply credentials.
:::note Note
The credential used for this is type [App Password](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/). An Atlassian Account API key will not work.
The credential required for this type is either an [Api token](https://support.atlassian.com/bitbucket-cloud/docs/using-api-tokens/), an [App Password](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/) or an [OAuth 2.0 client credentials](https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/). An Atlassian Account API key will not work.
:::
@@ -42,4 +62,7 @@ This one entry will have the following elements:
- `username`: The Bitbucket Cloud username to use in API requests. If
neither a username nor token are supplied, anonymous access will be used.
- `token`: The token used to authenticate requests.
- `appPassword`: The app password for the Bitbucket Cloud user.
- `clientId`: The OAuth client ID for Bitbucket Cloud (used with `clientSecret` for OAuth 2.0 client credentials flow).
- `clientSecret`: The OAuth client secret for Bitbucket Cloud (used with `clientId` for OAuth 2.0 client credentials flow).
docs/integrations/bitbucketServer/discovery.md
+2
View File
@@ -42,6 +42,8 @@ You need to decide how you want to receive events from external sources like
- [via HTTP endpoint](https://github.com/backstage/backstage/tree/master/plugins/events-backend/README.md)
- [via an AWS SQS queue](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md)
- [via Google Pub/Sub](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-google-pubsub/README.md)
- [via a Kafka topic](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-kafka/README.md)
Further documentation:
docs/integrations/github/discovery.md
+54 -2
View File
@@ -141,7 +141,7 @@ events:
region: us-east-2
```
The [AWS SQS module `README`](https://github.com/backstage/backstage/blob/master/plugins/events-backend-module-aws-sqs/README.md#configuration) has more details on the configuration options, the example above includes on the required options.
The [AWS SQS module `README`](https://github.com/backstage/backstage/blob/master/plugins/events-backend-module-aws-sqs/README.md#configuration) has more details on the configuration options, the example above includes only the required options.
### Events Setup using Google Pub/Sub module
@@ -179,7 +179,53 @@ events:
targetTopic: 'github.{{ event.attributes.x-github-event }}'
```
The [Google Pub/Sub module `README`](https://github.com/backstage/backstage/blob/master/plugins/events-backend-module-google-pubsub/README.md#configuration) has more details on the configuration options, the example above includes on the required options.
The [Google Pub/Sub module `README`](https://github.com/backstage/backstage/blob/master/plugins/events-backend-module-google-pubsub/README.md#configuration) has more details on the configuration options, the example above includes only the required options.
### Events Setup using Kafka module
Alternatively to using the HTTP endpoint you can use the Kafka module, here's how.
First we need to add the package:
```bash title="from your Backstage root directory"
yarn --cwd packages/backend add @backstage/plugin-events-backend-module-kafka
```
Then we need to add it to your backend:
```ts title="in packages/backend/src/index.ts"
backend.add(import('@backstage/plugin-events-backend'));
backend.add(import('@backstage/plugin-events-backend-module-github'));
/* highlight-add-start */
backend.add(import('@backstage/plugin-events-backend-module-kafka'));
/* highlight-add-end */
```
Finally you will want to configure it:
```yaml title="app-config.yaml
events:
modules:
kafka:
kafkaConsumingEventPublisher:
# Client ID used by Backstage to identify when connecting to the Kafka cluster.
clientId: your-client-id
# List of brokers in the Kafka cluster to connect to.
brokers:
- broker1
- broker2
topics:
# Replace with actual topic name as expected by subscribers
- topic: 'backstage.topic'
kafka:
# The Kafka topics to subscribe to.
topics:
- topic1
# The GroupId to be used by the topic consumers.
groupId: your-group-id
```
The [Kafka module `README`](https://github.com/backstage/backstage/blob/master/plugins/events-backend-module-kafka/README.md#configuration) has more details on the configuration options, the example above includes only the required options.
## Configuration
@@ -210,6 +256,8 @@ catalog:
filters: # optional filters
branch: 'develop' # optional string
repository: '.*' # optional Regex
pageSizes:
repositories: 25
wildcardProviderId:
organization: 'new-org' # string
catalogPath: '/groups/**/*.yaml' # this will search all folders for files that end in .yaml
@@ -308,6 +356,10 @@ If you do so, `default` will be used as provider ID.
The amount of time that should pass before the first invocation happens.
- **`scope`** _(optional)_:
`'global'` or `'local'`. Sets the scope of concurrency control.
- **`pageSizes`** _(optional)_:
Configure page sizes for GitHub GraphQL API queries. This can help prevent `RESOURCE_LIMITS_EXCEEDED` errors.
- **`repositories`** _(optional)_:
Number of repositories to fetch per page. Defaults to `25`. Reduce this value if hitting API resource limits.
## GitHub API Rate Limits
docs/integrations/github/org.md
+16
View File
@@ -79,6 +79,10 @@ catalog:
initialDelay: { seconds: 30 }
frequency: { hours: 1 }
timeout: { minutes: 50 }
pageSizes:
teams: 25
teamMembers: 50
organizationMembers: 50
- id: ghe
githubUrl: https://ghe.mycompany.com
orgs: ['internal-1', 'internal-2', 'internal-3']
@@ -86,6 +90,7 @@ catalog:
initialDelay: { seconds: 30 }
frequency: { hours: 1 }
timeout: { minutes: 50 }
excludeSuspendedUsers: true
```
Directly under the `githubOrg` is a list of configurations, each entry is a structure with the following elements:
@@ -94,6 +99,15 @@ Directly under the `githubOrg` is a list of configurations, each entry is a stru
- `githubUrl`: The target that this provider should consume
- `orgs` (optional): The list of the GitHub orgs to consume. If you only list a single org the generated group entities will use the `default` namespace, otherwise they will use the org name as the namespace. By default the provider will consume all accessible orgs on the given GitHub instance (support for GitHub App integration only).
- `schedule`: The refresh schedule to use, matches the structure of [`SchedulerServiceTaskScheduleDefinitionConfig`](https://backstage.io/docs/reference/backend-plugin-api.schedulerservicetaskscheduledefinitionconfig/)
- `pageSizes` (optional): Configure page sizes for GitHub GraphQL API queries to prevent `RESOURCE_LIMITS_EXCEEDED` errors. You can configure the following page sizes:
- `teams`: Number of teams to fetch per page when querying organization teams (default: 25)
- `teamMembers`: Number of team members to fetch per page when querying team members (default: 50)
- `organizationMembers`: Number of organization members to fetch per page (default: 50)
Reducing page sizes will result in more API calls and slightly longer sync times, but will prevent API resource limits for organizations with large number of teams and members.
- `excludeSuspendedUsers` (optional): Whether to exclude suspended users when querying organization users. Only for GitHub Enterprise instances. Will error if used against GitHub.com API.
### Events Support
@@ -118,6 +132,8 @@ You can decide between the following options (extensible):
- [via HTTP endpoint](https://github.com/backstage/backstage/tree/master/plugins/events-backend/README.md)
- [via an AWS SQS queue](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md)
- [via Google Pub/Sub](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-google-pubsub/README.md)
- [via a Kafka topic](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-kafka/README.md)
You can check the official docs to [configure your webhook](https://docs.github.com/en/developers/webhooks-and-events/webhooks/creating-webhooks) and to [secure your request](https://docs.github.com/en/developers/webhooks-and-events/webhooks/securing-your-webhooks).
The webhook will need to be configured to forward `organization`,`team` and `membership` events.
docs/integrations/gitlab/discovery.md
+4
View File
@@ -43,6 +43,8 @@ You need to decide how you want to receive events from external sources like
- [via HTTP endpoint](https://github.com/backstage/backstage/blob/master/plugins/events-backend/README.md#configuration)
- [via an AWS SQS queue](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md)
- [via Google Pub/Sub](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-google-pubsub/README.md)
- [via a Kafka topic](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-kafka/README.md)
Further documentation:
@@ -92,6 +94,8 @@ Additionally, you need to decide how you want to receive events from external so
- [via HTTP endpoint](https://github.com/backstage/backstage/tree/master/plugins/events-backend/README.md)
- [via an AWS SQS queue](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md)
- [via Google Pub/Sub](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-google-pubsub/README.md)
- [via a Kafka topic](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-kafka/README.md)
Set up your provider
docs/integrations/gitlab/org.md
+4
View File
@@ -49,6 +49,8 @@ You need to decide how you want to receive events from external sources like
- [via HTTP endpoint](https://github.com/backstage/backstage/blob/master/plugins/events-backend/README.md#configuration)
- [via an AWS SQS queue](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md)
- [via Google Pub/Sub](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-google-pubsub/README.md)
- [via a Kafka topic](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-kafka/README.md)
Further documentation:
@@ -101,6 +103,8 @@ Additionally, you need to decide how you want to receive events from external so
- [via HTTP endpoint](https://github.com/backstage/backstage/tree/master/plugins/events-backend/README.md)
- [via an AWS SQS queue](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-aws-sqs/README.md)
- [via Google Pub/Sub](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-google-pubsub/README.md)
- [via a Kafka topic](https://github.com/backstage/backstage/tree/master/plugins/events-backend-module-kafka/README.md)
Set up your provider
docs/notifications/index.md
+55
View File
@@ -164,6 +164,61 @@ You can customize the origin names shown in the UI by passing an object where th
Each notification processor will receive its own row in the settings page, where the user can enable or disable notifications from that processor.
### Default notification settings
You can configure default notification settings for all users in your `app-config.yaml` file. This allows you to set up notification preferences globally, such as disabling specific channels or origins by default, implementing an opt-in strategy instead of opt-out.
#### Channel-level defaults
You can set a default enabled state for an entire channel. When set to `false`, the channel uses an opt-in strategy where notifications are disabled by default unless explicitly enabled by the user or for specific origins.
```yaml
notifications:
defaultSettings:
channels:
- id: 'Web'
enabled: false # Opt-in strategy: channel disabled by default
- id: 'Email'
enabled: true # Opt-out strategy: channel enabled by default (default behavior)
```
#### Origin-level defaults
You can also configure defaults for specific origins within a channel:
```yaml
notifications:
defaultSettings:
channels:
- id: 'Web'
enabled: true # Channel is enabled by default
origins:
- id: 'plugin:scaffolder'
enabled: false # Disable scaffolder notifications by default
- id: 'plugin:catalog'
enabled: true # Enable catalog notifications by default
```
#### Topic-level defaults
For even more granular control, you can set defaults for specific topics within origins:
```yaml
notifications:
defaultSettings:
channels:
- id: 'Email'
enabled: false # Email is opt-in by default
origins:
- id: 'plugin:catalog'
enabled: true # But catalog notifications are enabled
topics:
- id: 'entity:validation:error'
enabled: false # Except validation errors
```
**Note:** If a channel's `enabled` flag is not set, it defaults to `true` for backwards compatibility. When a channel is set to `enabled: false`, all origins within that channel default to disabled unless explicitly enabled.
### Automatic notification cleanup
Notifications are deleted automatically after a certain period of time to prevent the database from growing indefinitely
docs/notifications/processors.md
+52
View File
@@ -149,11 +149,63 @@ notifications:
broadcastChannels: # Optional, if you wish to support broadcast notifications.
- C12345678
username: 'Backstage Bot' # Optional, defaults to the name of the Slack App.
concurrencyLimit: 20 # Optional, number of messages allowed per interval. Defaults to 10.
throttleInterval: 1m # Optional, Accepts ISO-8601 duration, ms-style ("1m", "30s"), or HumanDuration ({ minutes: 2 }). Defaults to 1 minute
```
Multiple instances can be added in the `slack` array, allowing you to have multiple configurations if you need to send
messages to more than one Slack workspace. Org-Wide App installation is not currently supported.
### Broadcast Channel Routing
For more granular control over where broadcast notifications are sent, you can use `broadcastRoutes` to route notifications to different Slack channels based on their origin and/or topic. This is useful when you want different types of notifications to go to different channels.
```yaml
notifications:
processors:
slack:
- token: xoxb-XXXXXXXXX
# Legacy option - used as fallback when no routes match
broadcastChannels:
- general-notifications
# Route broadcasts based on origin and/or topic
broadcastRoutes:
# Most specific: matches both origin AND topic
- origin: plugin:catalog
topic: alerts
channel: catalog-alerts
# Origin only: all notifications from this origin
- origin: plugin:catalog
channel: catalog-updates
# Topic only: all notifications with this topic (any origin)
- topic: security
channel: security-team
# Multiple channels: send to several channels at once
- origin: external:monitoring
channel:
- ops-team
- on-call-alerts
```
#### Route Matching Precedence
Routes are evaluated in the following order of priority:
1. **Origin + Topic match** (most specific) - A route that specifies both `origin` and `topic` will match first
2. **Origin-only match** - A route with only `origin` specified (no `topic`)
3. **Topic-only match** - A route with only `topic` specified (no `origin`)
4. **Default fallback** - If no routes match, falls back to `broadcastChannels`
The first matching route wins. If no routes match and no `broadcastChannels` are configured, the broadcast notification will not be sent to Slack.
#### Configuration Options
| Property | Type | Description |
| --------- | ---------------------- | ------------------------------------------------------------------------------------------ |
| `origin` | `string` | Optional. The notification origin to match (e.g., `plugin:catalog`, `external:my-service`) |
| `topic` | `string` | Optional. The notification topic to match (e.g., `alerts`, `updates`, `security`) |
| `channel` | `string` or `string[]` | Required. The Slack channel(s) to send to. Can be channel IDs, channel names, or user IDs |
### Entity Requirements
Entities must be annotated with the following annotation:
docs/overview/versioning-policy.md
+1 -1
View File
@@ -177,7 +177,7 @@ When we say _Supporting_ a Node.js release, that means the following:
- New Backstage projects created with `@backstage/create-app` will have their `engines.node` version set accordingly.
- Dropping compatibility with unsupported releases is not considered a breaking change. This includes using new syntax or APIs, as well as bumping dependencies that drop support for these versions.
Based on the above Backstage supports Node.js 20 and 22 as of the `1.33.0` release.
Based on the above Backstage supports Node.js 22 and 24 as of the `1.46.0` release.
## TypeScript Releases
docs/overview/what-is-backstage.md
-2
View File
@@ -39,8 +39,6 @@ Out of the box, Backstage includes:
Backstage is a CNCF Incubation project after graduating from Sandbox. Read the announcement
[here](https://backstage.io/blog/2022/03/16/backstage-turns-two#out-of-the-sandbox-and-into-incubation).
<img src="https://backstage.io/img/cncf-white.svg" alt="CNCF logo" width="400" />
## Benefits
- For _engineering managers_, it allows you to maintain standards and best
docs/permissions/custom-rules.md
+1 -1
View File
@@ -159,7 +159,7 @@ To install custom rules in a plugin, we need to use the [`PermissionsRegistrySer
```typescript title="packages/backend/src/modules/catalogPermissionRules.ts"
import { createBackendModule } from '@backstage/backend-plugin-api';
import { catalogPermissionExtensionPoint } from '@backstage/plugin-catalog-node/alpha';
import { isInSystemRule } from './permissionPolicyExtension';
import { isInSystemRule } from './permissionsPolicyExtension';
export default createBackendModule({
pluginId: 'catalog',
docs/plugins/backend-plugin.md
+12 -3
View File
@@ -48,11 +48,20 @@ This will think for a bit, and then say `Listening on :7007`. In a different
terminal window, now run
```sh
curl localhost:7007/api/carmen/health
curl localhost:7007/api/carmen/todos
```
This should return `{"status":"ok"}`. Success! Press `Ctrl + c` to stop it
again.
You should see the following response:
```json
{
"items": []
}
```
:::note Note: The route shown here matches the default in the current backend plugin template. If you want a `/health` endpoint for health checks, you can add it to your router yourself.
:::
## Developing your Backend Plugin
docs/plugins/existing-plugins.md
-18
View File
@@ -1,18 +0,0 @@
---
id: existing-plugins
title: Existing plugins
description: Lists of existing open source plugins
---
## The Plugin Directory
Open source plugins that you can add to your Backstage deployment can be found
at:
https://backstage.io/plugins
![](https://backstage.io/blog/assets/marketplace.png)
## Links
- [[blog] The Plugin Directory is open](https://backstage.io/blog/2020/09/30/plugin-marketplace)
docs/plugins/index.md
+6
View File
@@ -23,3 +23,9 @@ This approach is equally beneficial if you conceive an idea for a potentially im
## Integration with the Software Catalog
Should your plugin complement the Software Catalog rather than exist as a standalone feature (for instance, as an additional tab or a card within an "Overview" tab), you'll find comprehensive guidance on achieving this integration in the [Integrating Plugin into Software Catalog guide](integrating-plugin-into-software-catalog.md).
## Existing Plugins
There are a plethora of existing community made plugins which can be found by going to the [Backstage Plugin Directory](https://backstage.io/plugins)
You can read more about it in this blog post: [The Plugin Directory is now open](https://backstage.io/blog/2020/09/30/plugin-marketplace/)
docs/plugins/integrating-plugin-into-software-catalog.md
+1 -1
View File
@@ -32,7 +32,7 @@ Creating the plugin...
### Reading entities from within your plugin
You can access the currently selected entity using the backstage api
[`useEntity`](../reference/plugin-catalog-react.useentity.md). For example,
[`useEntity`](https://backstage.io/api/stable/functions/_backstage_plugin-catalog-react.index.useEntity.html). For example,
```tsx
import { useEntity } from '@backstage/plugin-catalog-react';
docs/plugins/structure-of-a-plugin.md
+2 -2
View File
@@ -81,8 +81,8 @@ export const ExamplePage = examplePlugin.provide(
```
This is where the plugin is created and where it creates and exports extensions
that can be imported and used the app. See reference docs for
[`createPlugin`](../reference/core-plugin-api.createplugin.md) or introduction to
that can be imported and used in the app. See reference docs for
[`createPlugin`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html) or introduction to
the new [Composability System](./composability.md).
## Components
docs/plugins/testing.md
+11
View File
@@ -4,6 +4,12 @@ title: Testing with Jest
description: Documentation on How to do unit testing with Jest
---
:::note Note
You may want to consider migrating to Jest 30, to do this, you can follow this guide: [Migrating to Jest 30](../tutorials/jest30-migration.md)
:::
Backstage uses [Jest](https://facebook.github.io/jest/) for all our unit testing
needs.
@@ -185,6 +191,11 @@ loading is broken, not that the loading indicator is broken.
## Examples
For more specific examples of how to test your Backstage **backend plugins** and **modules** or **frontend plugins** you can check out the following guides:
- [Testing Backend Plugins and Modules](../backend-system/building-plugins-and-modules/02-testing.md)
- [Testing Frontend Plugins](../frontend-system/building-plugins/02-testing.md)
### Utility Functions
A utility function is a function with no side effects. It takes in arguments and
docs/publishing.md
+11 -5
View File
@@ -69,17 +69,23 @@ Once the release has been published edit the newly created release in the [GitHu
**This emergency release process is intended only for the Backstage
maintainers.**
Given one or more PRs towards master that we want to create a patch release for, run the following script from the repo root:
Given one or more PRs towards master that we want to create a patch release for, add them to the patch release queue by running the following command for each PR:
```bash
./scripts/patch-release-for-pr.js <pr-number> <pr-number-2> ...
yarn patch-pr <pr-number> <description>
```
Wait until the script has finished executing, at the end of the output you will find a link of the format `https://github.com/backstage/backstage/pull/new/patch-release-pr-...`. Open this link in your browser to create a PR for the patch release. Finish the sentence "This release fixes an issue where..." and create the PR.
This creates a patch file in the `.patches/` directory (e.g., `.patches/pr-12345.txt`) containing the description of the fix. The [sync_patch-release.yml](https://github.com/backstage/backstage/blob/master/.github/workflows/sync_patch-release.yml) workflow will automatically detect these patch files and create or update a "Patch Release" PR.
Once the PR has been approved and merged, the patch release will be automatically created. The patch release is complete when a notification has been posted to Discord in the `#announcements` channel. Keep an eye on "Deploy Packages" workflow and re-trigger if it fails. It is safe to re-trigger any part of this workflow, including the release step.
The workflow will:
If the above process fails, you can fall back to the manual process documented below.
- Automatically create a patch release PR if one doesn't exist
- Update the existing PR if patch files are added, modified, or removed
- Close and delete the PR branch if all patch files are removed
Once the "Patch Release" PR has been approved and merged, the patch release will be automatically created. The patch files will be automatically removed from the master branch after the patch release is merged. From here the patch release process is the same as the usual release process, starting with the notification in the `#maintainers` channel on Discord.
If the above process fails, you can fall back to the manual process documented below, or run the `./scripts/patch-release-for-pr.js <pr-number> <pr-number-2> ...` script to manually create a patch release PR.
### Old Process
docs/releases/v1.45.0-changelog.md
+2607
View File
File diff suppressed because it is too large Load Diff
docs/releases/v1.45.0-next.1-changelog.md
+9366
View File
File diff suppressed because it is too large Load Diff
docs/releases/v1.45.0-next.2-changelog.md
+1448
View File
File diff suppressed because it is too large Load Diff
docs/releases/v1.45.0-next.3-changelog.md
+282
View File
@@ -0,0 +1,282 @@
# Release v1.45.0-next.3
Upgrade Helper: [https://backstage.github.io/upgrade-helper/?to=1.45.0-next.3](https://backstage.github.io/upgrade-helper/?to=1.45.0-next.3)
## @backstage/backend-plugin-api@1.5.0-next.2
### Minor Changes
- 62fc2de: Explicitly mark `coreServices.rootInstanceMetadata` as a root service.
## @backstage/repo-tools@0.16.0-next.2
### Minor Changes
- 11c61f2: The `package-docs` command will now automatically use a `typedoc.json` file if one exists at the root of your project.
### Patch Changes
- Updated dependencies
- @backstage/backend-plugin-api@1.5.0-next.2
## @backstage/ui@0.9.0-next.3
### Minor Changes
- 83c100e: **BREAKING**: Removed `Collapsible` component. Migrate to `Accordion` or use React Aria `Disclosure`.
## Migration Path 1: Accordion (Opinionated Styled Component)
Accordion provides preset styling with a similar component structure.
```diff
- import { Collapsible } from '@backstage/ui';
+ import { Accordion, AccordionTrigger, AccordionPanel } from '@backstage/ui';
- <Collapsible.Root>
- <Collapsible.Trigger render={(props) => <Button {...props}>Toggle</Button>} />
- <Collapsible.Panel>Content</Collapsible.Panel>
- </Collapsible.Root>
+ <Accordion>
+ <AccordionTrigger title="Toggle" />
+ <AccordionPanel>Content</AccordionPanel>
+ </Accordion>
```
CSS classes: `.bui-CollapsibleRoot` → `.bui-Accordion`, `.bui-CollapsibleTrigger` → `.bui-AccordionTrigger` (now on heading element), `.bui-CollapsiblePanel` → `.bui-AccordionPanel`
## Migration Path 2: React Aria Disclosure (Full Customization)
For custom styling without preset styles:
```tsx
import { Disclosure, Button, DisclosurePanel } from 'react-aria-components';
<Disclosure>
<Button slot="trigger">Toggle</Button>
<DisclosurePanel>Content</DisclosurePanel>
</Disclosure>;
```
- 816af0f: **BREAKING**: The `SelectProps` interface now accepts a generic type parameter for selection mode.
Added searchable and multiple selection support to Select component. The component now accepts `searchable`, `selectionMode`, and `searchPlaceholder` props to enable filtering and multi-selection modes.
Migration: If you're using `SelectProps` type directly, update from `SelectProps` to `SelectProps<'single' | 'multiple'>`. Component usage remains backward compatible.
### Patch Changes
- 35a3614: Fixed CSS issues in Select component including popover width constraints, focus outline behavior, and overflow handling.
- 01476f0: Improved visual consistency of PasswordField, SearchField, and MenuAutocomplete components.
- 836b0c7: Fixed dialog backdrop appearance in dark mode.
- 6d35a6b: Removed `@base-ui-components/react` dependency as all components now use React Aria Components.
- 7839e7b: Added `loading` prop to Button and ButtonIcon components for displaying spinner during async operations.
- a00fb88: Fixed Table Row component to properly support opening links in new tabs via right-click or Cmd+Click when using the href prop.
## @backstage/plugin-notifications-backend@0.6.0-next.2
### Minor Changes
- 87e597c: Adds support for default configuration for an entire notification channel.
This setting will also be inherited down to origins and topics while still respecting the users individual choices.
This will be handy if you want to use a "opt-in" strategy.
### Patch Changes
- Updated dependencies
- @backstage/plugin-notifications-common@0.2.0-next.1
- @backstage/backend-plugin-api@1.5.0-next.2
- @backstage/plugin-notifications-node@0.2.21-next.2
## @backstage/plugin-notifications-common@0.2.0-next.1
### Minor Changes
- 87e597c: Adds support for default configuration for an entire notification channel.
This setting will also be inherited down to origins and topics while still respecting the users individual choices.
This will be handy if you want to use a "opt-in" strategy.
## @backstage/backend-test-utils@1.10.0-next.2
### Patch Changes
- f3001fd: Tweak some of the mock services to have more precise types
- Updated dependencies
- @backstage/backend-plugin-api@1.5.0-next.2
## @backstage/core-components@0.18.3-next.2
### Patch Changes
- 96ad674: Line numbers in LogViewer will not be selectable in UI anymore
## @backstage/create-app@0.7.6-next.3
### Patch Changes
- Bumped create-app version.
## @backstage/frontend-plugin-api@0.12.2-next.2
### Patch Changes
- 7c6a66d: Added support for plugin-relative `attachTo` declarations for extension definitions. This allows for the creation of extension and extension blueprints that attach to other extensions of a particular `kind` in the same plugin, rather than needing to provide the exact extension ID. This is particularly useful when wanting to provide extension blueprints with a built-in hierarchy where the extensions created from one blueprint attach to extensions created from the other blueprint, for example:
```ts
// kind: 'tabbed-page'
const parentPage = TabbedPageBlueprint.make({
params: {....}
})
// attachTo: { kind: 'tabbed-page', input: 'tabs' }
const child1 = TabContentBlueprint.make({
name: 'tab1',
params: {....}
})
```
- Updated dependencies
- @backstage/core-components@0.18.3-next.2
## @backstage/plugin-app-visualizer@0.1.25-next.2
### Patch Changes
- 722e2df: Migrated to use `@backstage/ui`.
- Updated dependencies
- @backstage/ui@0.9.0-next.3
- @backstage/frontend-plugin-api@0.12.2-next.2
- @backstage/core-components@0.18.3-next.2
## @backstage/plugin-catalog-graph@0.5.3-next.2
### Patch Changes
- a2d7ae7: Ensure the catalog graph entity card respects the height prop so the visualization scales down properly on wide screens.
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.3-next.2
- @backstage/frontend-plugin-api@0.12.2-next.2
- @backstage/core-components@0.18.3-next.2
## @backstage/plugin-catalog-react@1.21.3-next.2
### Patch Changes
- 36d7582: Added missing i18n
- Updated dependencies
- @backstage/frontend-plugin-api@0.12.2-next.2
- @backstage/core-components@0.18.3-next.2
## @backstage/plugin-home@0.8.14-next.1
### Patch Changes
- 2ac5d29: Allow customization of VisitList by adding optional enrichVisit, transformPathname, canSave functions to VisitsStorageApi, along with VisitDisplayProvider for colors, labels
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.3-next.2
- @backstage/frontend-plugin-api@0.12.2-next.2
- @backstage/core-components@0.18.3-next.2
## @backstage/plugin-kubernetes-backend@0.20.4-next.2
### Patch Changes
- 1906d37: Updated dependency `@kubernetes/client-node` to `1.4.0`.
- Updated dependencies
- @backstage/backend-plugin-api@1.5.0-next.2
- @backstage/plugin-kubernetes-common@0.9.8-next.1
- @backstage/plugin-kubernetes-node@0.3.6-next.2
## @backstage/plugin-kubernetes-common@0.9.8-next.1
### Patch Changes
- 1906d37: Updated dependency `@kubernetes/client-node` to `1.4.0`.
## @backstage/plugin-kubernetes-node@0.3.6-next.2
### Patch Changes
- 1906d37: Updated dependency `@kubernetes/client-node` to `1.4.0`.
- Updated dependencies
- @backstage/backend-plugin-api@1.5.0-next.2
- @backstage/plugin-kubernetes-common@0.9.8-next.1
## @backstage/plugin-kubernetes-react@0.5.13-next.1
### Patch Changes
- 1906d37: Updated dependency `@kubernetes/client-node` to `1.4.0`.
- Updated dependencies
- @backstage/plugin-kubernetes-common@0.9.8-next.1
- @backstage/core-components@0.18.3-next.2
## @backstage/plugin-notifications@0.5.11-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-notifications-common@0.2.0-next.1
- @backstage/frontend-plugin-api@0.12.2-next.2
- @backstage/core-components@0.18.3-next.2
## @backstage/plugin-notifications-backend-module-email@0.3.16-next.2
### Patch Changes
- Updated dependencies
- @backstage/plugin-notifications-common@0.2.0-next.1
- @backstage/backend-plugin-api@1.5.0-next.2
- @backstage/plugin-notifications-node@0.2.21-next.2
## @backstage/plugin-notifications-backend-module-slack@0.2.1-next.2
### Patch Changes
- Updated dependencies
- @backstage/plugin-notifications-common@0.2.0-next.1
- @backstage/backend-plugin-api@1.5.0-next.2
- @backstage/plugin-notifications-node@0.2.21-next.2
## @backstage/plugin-notifications-node@0.2.21-next.2
### Patch Changes
- Updated dependencies
- @backstage/plugin-notifications-common@0.2.0-next.1
- @backstage/backend-plugin-api@1.5.0-next.2
## @backstage/plugin-org@0.6.46-next.1
### Patch Changes
- 6db9e7e: Improved responsiveness of GroupProfileCard component
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.3-next.2
- @backstage/frontend-plugin-api@0.12.2-next.2
- @backstage/core-components@0.18.3-next.2
## @backstage/plugin-scaffolder-backend-module-notifications@0.1.16-next.2
### Patch Changes
- Updated dependencies
- @backstage/plugin-notifications-common@0.2.0-next.1
- @backstage/backend-plugin-api@1.5.0-next.2
- @backstage/plugin-notifications-node@0.2.21-next.2
## example-backend@0.0.44-next.2
### Patch Changes
- Updated dependencies
- @backstage/plugin-notifications-backend@0.6.0-next.2
- @backstage/backend-plugin-api@1.5.0-next.2
- @backstage/plugin-kubernetes-backend@0.20.4-next.2
- @backstage/plugin-scaffolder-backend-module-notifications@0.1.16-next.2
- @backstage/plugin-catalog-backend@3.2.0-next.1
- @backstage/plugin-events-backend@0.5.8-next.1
- @backstage/plugin-scaffolder-backend@3.0.1-next.1
- @backstage/plugin-search-backend@2.0.8-next.1
docs/releases/v1.45.0.md
+72
View File
@@ -0,0 +1,72 @@
---
id: v1.45.0
title: v1.45.0
description: Backstage Release v1.45.0
---
These are the release notes for the v1.45.0 release of [Backstage](https://backstage.io/).
A huge thanks to the whole team of maintainers and contributors as well as the amazing Backstage Community for the hard work in getting this release developed and done.
## Highlights
### Backstage UI: Breaking Changes + New Components
Multiple components migrated from Base UI to React Aria Components including `Avatar`, `Checkbox`, and removal of the `Collapsible` component in favour of `Accordion`.
Check the [CHANGELOG.md](https://github.com/backstage/backstage/blob/master/packages/ui/CHANGELOG.md) for more migration guides on any breaking changes that come with these latest updates.
### BREAKING: `ldapjs` -> `ldapts`
Moved from deprecated `ldapjs` dependency to `ldapts`, with breaking changes to custom transformer types and search options.
Contributed by [@ganives](https://github.com/ganievs) in [#30594](https://github.com/backstage/backstage/pull/30594)
Check the [CHANGELOG.md](https://github.com/backstage/backstage/blob/master/plugins/catalog-backend-module-ldap/CHANGELOG.md) for more migration guides on any breaking changes that come with these latest updates.
### NFS: Plugin-Relative Extension Attachments
Added support for plugin-relative `attachTo` declarations for extension definitions, allowing extensions to attach to other extensions of a particular kind in the same plugin rather than requiring exact extension IDs.
### NFS: Forwards Compatibility for Route Refs
It is now possible to use route references from the old frontend system directly in the new one. That means there's no longer a need to use `convertLegacyRouteRef` or `convertLegacyRouteRefs` to re-use route refs in implementations for the new system. This both simplifies migration, and reduces risk for cross system issues while partially migrated.
This requires no immediate action on your part. As long as a plugin intends to support the old system, it can still keep defining its route refs using the old system without issues. And calling `convertLegacyRouteRef` or `convertLegacyRouteRefs` does not cause problems.
### Configurable Dynamic Client Registration Token Expiration
Allow configuring dynamic client registration token expiration with config `auth.experimentalDynamicClientRegistration.tokenExpiration`. Maximum expiration for the DCR token is 24 hours. Default expiration is 1 hour. Contributed by [@drodil](https://github.com/drodil) in [#31278](https://github.com/backstage/backstage/pull/31278)
### Support for Bitbucket Cloud API tokens
Since Bitbucket Cloud is phasing out support for the `appPassword` tokens, you can now instead specify the more modern API tokens using the `token` field of your Bitbucket config.
### Support for PostgreSQL 18
The default setup for `TestDatabases` will start running tests against PG14 and PG18 where available, instead of PG13 and PG17 as previously. If you pass in explicit database IDs to your test database instance, those will still be respected.
### `coreServices.rootInstanceMetadata` is stable
The backend service `coreServices.rootInstanceMetadata` is now available as stable. It currently has one method - that lets you list all of the installed backend plugins and their modules on the current instance.
## Security Fixes
This release does not contain any security fixes.
## Upgrade path
We recommend that you keep your Backstage project up to date with this latest release. For more guidance on how to upgrade, check out the documentation for [keeping Backstage updated](https://backstage.io/docs/getting-started/keeping-backstage-updated).
## Links and References
Below you can find a list of links and references to help you learn about and start using this new release.
- [Backstage official website](https://backstage.io/), [documentation](https://backstage.io/docs/), and [getting started guide](https://backstage.io/docs/getting-started/)
- [GitHub repository](https://github.com/backstage/backstage)
- Backstage's [versioning and support policy](https://backstage.io/docs/overview/versioning-policy)
- [Community Discord](https://discord.gg/backstage-687207715902193673) for discussions and support
- [Changelog](https://github.com/backstage/backstage/tree/master/docs/releases/v1.45.0-changelog.md)
- Backstage [Demos](https://backstage.io/demos), [Blog](https://backstage.io/blog), [Roadmap](https://backstage.io/docs/overview/roadmap) and [Plugins](https://backstage.io/plugins)
Sign up for our [newsletter](https://info.backstage.spotify.com/newsletter_subscribe) if you want to be informed about what is happening in the world of Backstage.
docs/releases/v1.46.0-changelog.md
+2369
View File
File diff suppressed because it is too large Load Diff
docs/releases/v1.46.0-next.0-changelog.md
+2269
View File
File diff suppressed because it is too large Load Diff
docs/releases/v1.46.0-next.1-changelog.md
+392
View File
@@ -0,0 +1,392 @@
# Release v1.46.0-next.1
Upgrade Helper: [https://backstage.github.io/upgrade-helper/?to=1.46.0-next.1](https://backstage.github.io/upgrade-helper/?to=1.46.0-next.1)
## @backstage/plugin-techdocs-addons-test-utils@2.0.0-next.1
### Major Changes
- 8d6709e: **BREAKING**: `TechDocsAddonTester.renderWithEffects()` no longer returns a screen; this means that you can no longer grab assertions such as `getByText` from its return value.
Newer versions of `@testing-library` recommends using the `screen` export for assertions - and removing this from the addon tester contract allows us to more freely iterate on which underlying version of the testing library is being used.
One notable effect of this, however, is that the `@testing-library` `screen` does NOT support assertions on the shadow DOM, which techdocs relies on. You will therefore want to add a dependency on [the `shadow-dom-testing-library` package](https://github.com/konnorrogers/shadow-dom-testing-library/) in your tests, and using its `screen` and its dedicated `*Shadow*` methods. As an example, if you keep doing `getByText` you will not get matches inside the shadow DOM - switch to `getByShadowText` instead.
```ts
import { screen } from 'shadow-dom-testing-library';
// ... render the addon ...
await TechDocsAddonTester.buildAddonsInTechDocs([<AnAddon />])
.withDom(<body>TEST_CONTENT</body>)
.renderWithEffects();
expect(screen.getByShadowText('TEST_CONTENT')).toBeInTheDocument();
```
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.4-next.1
- @backstage/plugin-techdocs@1.16.1-next.1
## @backstage/ui@0.10.0-next.1
### Minor Changes
- 16543fa: **Breaking change** The `Cell` component has been refactored to be a generic wrapper component that accepts `children` for custom cell content. The text-specific functionality (previously part of `Cell`) has been moved to a new `CellText` component.
### Migration Guide
If you were using `Cell` with text-specific props (`title`, `description`, `leadingIcon`, `href`), you need to update your code to use `CellText` instead:
**Before:**
```tsx
<Cell
title="My Title"
description="My description"
leadingIcon={<Icon />}
href="/path"
/>
```
**After:**
```tsx
<CellText
title="My Title"
description="My description"
leadingIcon={<Icon />}
href="/path"
/>
```
For custom cell content, use the new generic `Cell` component:
```tsx
<Cell>{/* Your custom content */}</Cell>
```
### Patch Changes
- 50b7927: Fixed Checkbox indicator showing checkmark color when unchecked.
Affected components: Checkbox
- 5bacf55: Fixed `ButtonIcon` incorrectly applying `className` to inner elements instead of only the root element.
Affected components: ButtonIcon
- a20d317: Added row selection support with visual state styling for hover, selected, and pressed states. Fixed checkbox rendering to only show for multi-select toggle mode.
Affected components: Table, TableHeader, Row, Column
## @backstage/cli@0.34.6-next.1
### Patch Changes
- 7fbac5c: Updated to use new utilities from `@backstage/cli-common`.
- Updated dependencies
- @backstage/cli-node@0.2.16-next.1
- @backstage/cli-common@0.1.16-next.1
## @backstage/cli-common@0.1.16-next.1
### Patch Changes
- 5cfb2a4: Added new `run`, `runOutput`, and `runCheck` utilities to help run child processes in a safe and portable way.
## @backstage/cli-node@0.2.16-next.1
### Patch Changes
- 4e8c726: Updated to use new utilities from `@backstage/cli-common`.
- Updated dependencies
- @backstage/cli-common@0.1.16-next.1
## @backstage/codemods@0.1.53-next.1
### Patch Changes
- 688f070: Updated to use new utilities from `@backstage/cli-common`.
- Updated dependencies
- @backstage/cli-common@0.1.16-next.1
## @backstage/core-components@0.18.4-next.1
### Patch Changes
- 9a942a4: Fixed bug in the `LogViewer` component where shift + click always opened a new window instead of just changing the selection.
In addition, improved the `LogViewer` component by a few usability enhancements:
- Added support for multiple selections using cmd/ctrl + click
- Improved the generated hash that is added to the URL to also support ranges & multiple selections
- Added an hover effect & info tooltip to the "Copy to clipboard" button to indicate its functionality
- Added some color and a separator to the line numbers to improve readability
- 207c3c8: long words like urls now breaks to new line on warning panels instead of overflowing the container
- 5d52dab: Add i18n support for LogViewer search control
## @backstage/create-app@0.7.7-next.1
### Patch Changes
- Bumped create-app version.
- Updated dependencies
- @backstage/cli-common@0.1.16-next.1
## @backstage/dev-utils@1.1.18-next.1
### Patch Changes
- Updated dependencies
- @backstage/ui@0.10.0-next.1
- @backstage/core-components@0.18.4-next.1
- @backstage/plugin-catalog-react@1.21.4-next.1
## @backstage/repo-tools@0.16.1-next.1
### Patch Changes
- 688f070: Updated to use new utilities from `@backstage/cli-common`.
- d1e38a7: Properly create workspace in OS temporary directory for `generate-patch` command
- Updated dependencies
- @backstage/cli-node@0.2.16-next.1
- @backstage/cli-common@0.1.16-next.1
## @techdocs/cli@1.10.3-next.1
### Patch Changes
- 43629b1: Updated to use new utilities from `@backstage/cli-common`.
- Updated dependencies
- @backstage/cli-common@0.1.16-next.1
## @backstage/plugin-app-visualizer@0.1.26-next.1
### Patch Changes
- Updated dependencies
- @backstage/ui@0.10.0-next.1
- @backstage/core-components@0.18.4-next.1
## @backstage/plugin-catalog-backend-module-aws@0.4.18-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-kubernetes-common@0.9.9-next.0
## @backstage/plugin-catalog-backend-module-gcp@0.3.15-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-kubernetes-common@0.9.9-next.0
## @backstage/plugin-catalog-backend-module-github@0.11.3-next.1
### Patch Changes
- ed5a7a3: Introduce new configuration option to exclude suspended users from GitHub Enterprise instances.
When it’s set to true, suspended users won’t be returned when querying the organization users for GitHub Enterprise instances.
Note that this option should be used only against GitHub Enterprise instances, the property does not exist in the github.com GraphQL schema, setting it will cause a schema validation error and the syncing of users will fail.
## @backstage/plugin-catalog-backend-module-github-org@0.3.17-next.1
### Patch Changes
- ed5a7a3: Introduce new configuration option to exclude suspended users from GitHub Enterprise instances.
When it’s set to true, suspended users won’t be returned when querying the organization users for GitHub Enterprise instances.
Note that this option should be used only against GitHub Enterprise instances, the property does not exist in the github.com GraphQL schema, setting it will cause a schema validation error and the syncing of users will fail.
- Updated dependencies
- @backstage/plugin-catalog-backend-module-github@0.11.3-next.1
## @backstage/plugin-catalog-backend-module-unprocessed@0.6.7-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-unprocessed-entities-common@0.0.12-next.0
## @backstage/plugin-catalog-react@1.21.4-next.1
### Patch Changes
- 6d39141: Fixed an issue where `EntityOwnerPicker` failed to filter options when the input text contained uppercase characters.
- Updated dependencies
- @backstage/core-components@0.18.4-next.1
## @backstage/plugin-catalog-unprocessed-entities@0.2.24-next.1
### Patch Changes
- df4d646: Moved types, API and client to the common package, allowing both frontend and
backend plugins to use the `CatalogUnprocessedEntitiesClient`.
The following types, clients and interfaces have been deprecated and should be
imported from the `@backstage/plugin-catalog-unprocessed-entities-common` instead:
`CatalogUnprocessedEntitiesApi`, `CatalogUnprocessedEntitiesApiResponse`, `UnprocessedEntity`,
`UnprocessedEntityCache`, `UnprocessedEntityError`, `CatalogUnprocessedEntitiesClient`.
All those types, clients and interfaces are re-exported temporarily in the
`@backstage/plugin-catalog-unprocessed-entities` package until cleaned up.
- Updated dependencies
- @backstage/core-components@0.18.4-next.1
- @backstage/plugin-catalog-unprocessed-entities-common@0.0.12-next.0
## @backstage/plugin-catalog-unprocessed-entities-common@0.0.12-next.0
### Patch Changes
- df4d646: Moved types, API and client to the common package, allowing both frontend and
backend plugins to use the `CatalogUnprocessedEntitiesClient`.
The following types, clients and interfaces have been deprecated and should be
imported from the `@backstage/plugin-catalog-unprocessed-entities-common` instead:
`CatalogUnprocessedEntitiesApi`, `CatalogUnprocessedEntitiesApiResponse`, `UnprocessedEntity`,
`UnprocessedEntityCache`, `UnprocessedEntityError`, `CatalogUnprocessedEntitiesClient`.
All those types, clients and interfaces are re-exported temporarily in the
`@backstage/plugin-catalog-unprocessed-entities` package until cleaned up.
## @backstage/plugin-kubernetes@0.12.14-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-kubernetes-react@0.5.14-next.1
- @backstage/core-components@0.18.4-next.1
- @backstage/plugin-catalog-react@1.21.4-next.1
- @backstage/plugin-kubernetes-common@0.9.9-next.0
## @backstage/plugin-kubernetes-backend@0.20.5-next.1
### Patch Changes
- 8fa8d87: Add Kubernetes Plugin Secrets Accordion with masked secret datas
- Updated dependencies
- @backstage/plugin-kubernetes-common@0.9.9-next.0
- @backstage/plugin-kubernetes-node@0.3.7-next.1
## @backstage/plugin-kubernetes-cluster@0.0.32-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-kubernetes-react@0.5.14-next.1
- @backstage/core-components@0.18.4-next.1
- @backstage/plugin-catalog-react@1.21.4-next.1
- @backstage/plugin-kubernetes-common@0.9.9-next.0
## @backstage/plugin-kubernetes-common@0.9.9-next.0
### Patch Changes
- 8fa8d87: Add Kubernetes Plugin Secrets Accordion with masked secret datas
## @backstage/plugin-kubernetes-node@0.3.7-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-kubernetes-common@0.9.9-next.0
## @backstage/plugin-kubernetes-react@0.5.14-next.1
### Patch Changes
- f966a85: Enabled a pod terminal at GKE
- 8fa8d87: Add Kubernetes Plugin Secrets Accordion with masked secret datas
- Updated dependencies
- @backstage/core-components@0.18.4-next.1
- @backstage/plugin-kubernetes-common@0.9.9-next.0
## @backstage/plugin-mui-to-bui@0.2.2-next.1
### Patch Changes
- Updated dependencies
- @backstage/ui@0.10.0-next.1
## @backstage/plugin-scaffolder-react@1.19.4-next.1
### Patch Changes
- 5ca461e: Fixed bug where custom `review.name` values were incorrectly formatted by `startCase`, preserving them exactly as written.
- Updated dependencies
- @backstage/core-components@0.18.4-next.1
- @backstage/plugin-catalog-react@1.21.4-next.1
## @backstage/plugin-techdocs@1.16.1-next.1
### Patch Changes
- 592361e: The `techdocs` config is now marked as optional.
- Updated dependencies
- @backstage/core-components@0.18.4-next.1
- @backstage/plugin-catalog-react@1.21.4-next.1
## @backstage/plugin-techdocs-backend@2.1.3-next.1
### Patch Changes
- 592361e: The `techdocs` config is now marked as optional.
## @backstage/plugin-techdocs-module-addons-contrib@1.1.31-next.1
### Patch Changes
- 8d6709e: Updated tests to match test-utils change
- Updated dependencies
- @backstage/core-components@0.18.4-next.1
## example-app@0.2.116-next.1
### Patch Changes
- Updated dependencies
- @backstage/ui@0.10.0-next.1
- @backstage/core-components@0.18.4-next.1
- @backstage/plugin-techdocs-module-addons-contrib@1.1.31-next.1
- @backstage/plugin-catalog-react@1.21.4-next.1
- @backstage/plugin-scaffolder-react@1.19.4-next.1
- @backstage/plugin-catalog-unprocessed-entities@0.2.24-next.1
- @backstage/cli@0.34.6-next.1
- @backstage/plugin-techdocs@1.16.1-next.1
- @backstage/plugin-mui-to-bui@0.2.2-next.1
- @backstage/plugin-kubernetes@0.12.14-next.1
- @backstage/plugin-kubernetes-cluster@0.0.32-next.1
## example-app-next@0.0.30-next.1
### Patch Changes
- Updated dependencies
- @backstage/ui@0.10.0-next.1
- @backstage/core-components@0.18.4-next.1
- @backstage/plugin-techdocs-module-addons-contrib@1.1.31-next.1
- @backstage/plugin-catalog-react@1.21.4-next.1
- @backstage/plugin-scaffolder-react@1.19.4-next.1
- @backstage/plugin-catalog-unprocessed-entities@0.2.24-next.1
- @backstage/cli@0.34.6-next.1
- @backstage/plugin-techdocs@1.16.1-next.1
- @backstage/plugin-app-visualizer@0.1.26-next.1
- @backstage/plugin-kubernetes@0.12.14-next.1
- @backstage/plugin-kubernetes-cluster@0.0.32-next.1
## techdocs-cli-embedded-app@0.2.115-next.1
### Patch Changes
- Updated dependencies
- @backstage/ui@0.10.0-next.1
- @backstage/core-components@0.18.4-next.1
- @backstage/cli@0.34.6-next.1
- @backstage/plugin-techdocs@1.16.1-next.1
docs/releases/v1.46.0-next.2-changelog.md
+1897
View File
File diff suppressed because it is too large Load Diff
docs/releases/v1.46.0.md
+129
View File
@@ -0,0 +1,129 @@
---
id: v1.46.0
title: v1.46.0
description: Backstage Release v1.46.0
---
These are the release notes for the v1.46.0 release of [Backstage](https://backstage.io/).
A huge thanks to the whole team of maintainers and contributors as well as the amazing Backstage Community for the hard work in getting this release developed and done.
## Highlights
To begin with, this release has a few important framework level updates.
### **BREAKING:** Updated supported Node.js versions to 22 and 24
This release moves up the supported Node.js versions to 22 and 24, according to our [versioning policy](https://backstage.io/docs/overview/versioning-policy#nodejs-releases). As part of this change, we are also setting the compilation targets to ES2023, which lines up with the supported Node.js versions.
The default TypeScript `target` compiler option is however left at ES2022. This is because older versions of TypeScript will error if they see an unsupported value, even if an override is set in your local `tsconfig.json`. You can still choose to set the TypeScript `target` to either `ES2023` or even `ES2024` in your own `tsconfig.json` if you prefer.
### **BREAKING:** Switched modules to `ES2020` and resolution mode to `bundler`
Now that the ecosystem has had some time to mature and adapt, we have finally switched over the default module resolution mode to `bundler` instead of `node`. The `module` setting was also changed to `ES2022`.
You _may_ need to bump some dependencies as part of this change, or fix imports in code. The most common source of this is that type checking will now consider the `exports` field in `package.json` when resolving imports. This in turn can break older versions of packages that had incompatible `exports` fields. Generally these issues will have already been fixed in the upstream packages, but if you depend on old versions or unmaintained packages, you may still notice some effects of this.
You might be tempted to use `--skipLibCheck` to hide issues due to this change, but it will weaken the type safety of your project. If you run into a large number of issues and want to keep the old behavior, you can reset the `moduleResolution` and `module` settings of your own `tsconfig.json` file to `node` and `ESNext` respectively. But keep in mind that the `node` option will be removed in future versions of TypeScript.
A future version of Backstage will make these new settings mandatory, as we move to rely on the `exports` field for type resolution in packages, rather than the `typesVersions` field.
### **BREAKING:** Moving toward updating `jest` and its DOM
The `jest` test framework used to be a builtin dependency of the Backstage CLI. In this release, it has been made into a peer dependency to allow for easy upgrades to newer versions as you see fit.
If you run tests using the Backstage CLI, you must therefore add Jest and its environment dependencies as `devDependencies` in your project root `package.json` when you upgrade.
You can choose to install either Jest 29 or Jest 30. The built-in Jest version before this change was Jest 29, however, we recommend that you switch to Jest 30. Upgrading will solve the `Could not parse CSS stylesheet` errors, allow you to use MSW v2 in web packages, and ensure that you remain compatible with future versions of the Backstage CLI. Support for Jest 29 is temporary, with the purpose of allowing you to upgrade at your own pace, but it will eventually be removed.
- **Jest 29**: Install `jest@^29` and `jest-environment-jsdom@^29` in your root `package.json`. No migration needed, but you may see `Could not parse CSS stylesheet` warnings/errors when testing components from `@backstage/ui` or other packages using CSS `@layer` declarations.
- **Jest 30**: Install `jest@^30`, `@types/jest@^30`, `@jest/environment-jsdom-abstract@^30`, and `jsdom@^27` in your root `package.json`. Fixes the stylesheet parsing warnings/errors, but requires migration steps.
See the [Jest 30 migration guide](https://backstage.io/docs/tutorials/jest30-migration) for detailed migration instructions.
### **BREAKING:** Now using correct configuration options for Valkey
If you are using Valkey as your backend cache provider, take note. It used to piggyback on the Redis configuration format, but that was not quite correct. So its config options have been updated to better match its capabilities.
So if you use Valkey, you need to upgrade your `app-config.yaml`:
```diff
backend:
cache:
store: valkey
connection: ...
client:
- namespace: 'my-app'
- keyPrefixSeparator: ':'
+ keyPrefix: 'my-app:'
- clearBatchSize: 1000
- useUnlink: false
```
Contributed by [@benjidotsh](https://github.com/benjidotsh) in [#31497](https://github.com/backstage/backstage/pull/31497)
### **BREAKING:** Techdocs addon test utils removed explicit `screen`
`TechdocsAddonTester.renderWithEffects()` used to return a `screen` that you could use for things like `getByText`. In order to support moving to newer versions of `@testing-library`, we have removed this, and you should import and use the normal `screen` from `@testing-library/react` instead.
However: that `screen` can’t see inside the shadow DOM, which TechDocs uses. So if your tests need to look inside shadow DOM, you must install `shadow-dom-testing-library` and use its `screen` which provides special shadow-DOM queries, such as `getByShadowText` instead of `getByText.
Example:
```tsx
import { screen } from 'shadow-dom-testing-library';
// ... render the addon ...
await TechDocsAddonTester.buildAddonsInTechDocs([<AnAddon />])
.withDom(<body>TEST_CONTENT</body>)
.renderWithEffects();
expect(screen.getByShadowText('TEST_CONTENT')).toBeInTheDocument();
```
### **BREAKING:** Backstage-UI advances!
Again, Backstage-UI has a bunch of updates! One of them is breaking: If you were using the `Cell` component with text-specific props (`title` etc), you should now instead use the `CellText` component for that. Plain `Cell` is now meant to be used with generic child elements instead.
### Simplified route compatibility
If you are partway through a migration to the New Frontend System, you may enjoy the fact that the `useApp` and `useRouteRef` hooks now are forwards compatible with NFS. Along with the previous route reference changes this means that there is no longer a need to use `compatWrapper` from `@backstage/core-compat-api` to make code based on `@backstage/core-plugin-api` compatible with `@backstage/frontend-plugin-api` APIs.
### Support for Bitbucket Cloud OAuth
Support for Bitbucket Cloud OAuth has been added - which was much welcome. This introduces an alternative authentication method using a workspace OAuth consumer, alongside App Passwords (deprecated) and API tokens. OAuth does not require a bot or service account and avoids token expiry issues.
As part of this change, some breaking changes were made to low level auth getter functions, such that they now return a promise instead of a plain value.
Contributed by [@jksmth](https://github.com/jksmth) in [#31848](https://github.com/backstage/backstage/pull/31848)
### New Catalog actions
There are two new MCP-usable actions on the block for registering and unregistering entities: `catalog:register-entity` and `catalog:unregister-entity`.
Contributed by [@gabemontero](https://github.com/gabemontero) in [#32042](https://github.com/backstage/backstage/pull/32042)
### New `RepoOwnerPicker` for Scaffolder
A new field extension for selecting an organization or owner for a particular repository has been shipped! Currently, this only supports GitHub autocomplete, but contributions welcome in making this available for other providers!
Contributed by [@benjidotsh](https://github.com/benjidotsh) in [#32105](https://github.com/backstage/backstage/pull/32105)
## Security Fixes
This release does not contain any security fixes.
## Upgrade path
We recommend that you keep your Backstage project up to date with this latest release. For more guidance on how to upgrade, check out the documentation for [keeping Backstage updated](https://backstage.io/docs/getting-started/keeping-backstage-updated).
## Links and References
Below you can find a list of links and references to help you learn about and start using this new release.
- [Backstage official website](https://backstage.io/), [documentation](https://backstage.io/docs/), and [getting started guide](https://backstage.io/docs/getting-started/)
- [GitHub repository](https://github.com/backstage/backstage)
- Backstage's [versioning and support policy](https://backstage.io/docs/overview/versioning-policy)
- [Community Discord](https://discord.gg/backstage-687207715902193673) for discussions and support
- [Changelog](https://github.com/backstage/backstage/tree/master/docs/releases/v1.46.0-changelog.md)
- Backstage [Demos](https://backstage.io/demos), [Blog](https://backstage.io/blog), [Roadmap](https://backstage.io/docs/overview/roadmap) and [Plugins](https://backstage.io/plugins)
Sign up for our [newsletter](https://info.backstage.spotify.com/newsletter_subscribe) if you want to be informed about what is happening in the world of Backstage.
docs/releases/v1.47.0-changelog.md
+1467
View File
File diff suppressed because it is too large Load Diff
docs/releases/v1.47.0-next.0-changelog.md
+578
View File
@@ -0,0 +1,578 @@
# Release v1.47.0-next.0
Upgrade Helper: [https://backstage.github.io/upgrade-helper/?to=1.47.0-next.0](https://backstage.github.io/upgrade-helper/?to=1.47.0-next.0)
## @backstage/ui@0.11.0-next.0
### Minor Changes
- 4ea1d15: **BREAKING**: Renamed CSS variable `--bui-bg` to `--bui-bg-surface-0` for consistency.
### Patch Changes
- 1880402: Fixes app background color on dark mode.
- 9c76682: build(deps-dev): bump `storybook` from 10.1.9 to 10.1.10
- b4a4911: Fixed SearchField `startCollapsed` prop not working correctly in Backstage UI. The field now properly starts in a collapsed state, expands when clicked and focused, and collapses back when unfocused with no input. Also fixed CSS logic to work correctly in all layout contexts (flex row, flex column, and regular containers).
Affected components: SearchField
## @backstage/backend-defaults@0.14.1-next.0
### Patch Changes
- 7126bf2: Fixed a spelling mistake in root health service shutdown response.
- Updated dependencies
- @backstage/backend-app-api@1.4.0
- @backstage/backend-dev-utils@0.1.6
- @backstage/backend-plugin-api@1.6.0
- @backstage/cli-node@0.2.16
- @backstage/config@1.3.6
- @backstage/config-loader@1.10.7
- @backstage/errors@1.2.7
- @backstage/integration@1.19.0
- @backstage/integration-aws-node@0.1.19
- @backstage/types@1.2.2
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-events-node@0.4.18
- @backstage/plugin-permission-node@0.10.7
## @backstage/backend-dynamic-feature-service@0.7.8-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-openapi-utils@0.6.5-next.0
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/cli-common@0.1.16
- @backstage/cli-node@0.2.16
- @backstage/config@1.3.6
- @backstage/config-loader@1.10.7
- @backstage/errors@1.2.7
- @backstage/types@1.2.2
- @backstage/plugin-app-node@0.1.40
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-catalog-backend@3.3.1-next.0
- @backstage/plugin-events-backend@0.5.10-next.0
- @backstage/plugin-events-node@0.4.18
- @backstage/plugin-permission-common@0.9.3
- @backstage/plugin-permission-node@0.10.7
- @backstage/plugin-scaffolder-node@0.12.2
- @backstage/plugin-search-backend-node@1.4.0
- @backstage/plugin-search-common@1.2.21
## @backstage/backend-openapi-utils@0.6.5-next.0
### Patch Changes
- 6678b78: Internal update to use native feature from our request validation library for handling base path determination.
- Updated dependencies
- @backstage/backend-plugin-api@1.6.0
- @backstage/errors@1.2.7
- @backstage/types@1.2.2
## @backstage/backend-test-utils@1.10.3-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-app-api@1.4.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/types@1.2.2
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-events-node@0.4.18
- @backstage/plugin-permission-common@0.9.3
## @backstage/cli@0.35.2-next.0
### Patch Changes
- 320c6a9: Bump `@swc/core` to support `ES2023` and `ES2024`
- 9ee5996: Bump minimum required `@swc/core` to avoid transpilation bug
- Updated dependencies
- @backstage/catalog-model@1.7.6
- @backstage/cli-common@0.1.16
- @backstage/cli-node@0.2.16
- @backstage/config@1.3.6
- @backstage/config-loader@1.10.7
- @backstage/errors@1.2.7
- @backstage/eslint-plugin@0.2.0
- @backstage/integration@1.19.0
- @backstage/release-manifests@0.0.13
- @backstage/types@1.2.2
## @backstage/create-app@0.7.8-next.0
### Patch Changes
- Bumped create-app version.
- Updated dependencies
- @backstage/cli-common@0.1.16
## @backstage/dev-utils@1.1.19-next.0
### Patch Changes
- Updated dependencies
- @backstage/ui@0.11.0-next.0
- @backstage/app-defaults@1.7.3
- @backstage/catalog-model@1.7.6
- @backstage/core-app-api@1.19.3
- @backstage/core-components@0.18.4
- @backstage/core-plugin-api@1.12.1
- @backstage/integration-react@1.2.13
- @backstage/theme@0.7.1
- @backstage/plugin-catalog-react@1.21.4
## @techdocs/cli@1.10.4-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/catalog-model@1.7.6
- @backstage/cli-common@0.1.16
- @backstage/config@1.3.6
- @backstage/plugin-techdocs-node@1.13.10
## @backstage/plugin-app-visualizer@0.1.27-next.0
### Patch Changes
- Updated dependencies
- @backstage/ui@0.11.0-next.0
- @backstage/core-components@0.18.4
- @backstage/core-plugin-api@1.12.1
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-auth-backend-module-oidc-provider@0.4.11-next.0
### Patch Changes
- e54fcb2: Added support for custom start URL search parameters (with the new `startUrlSearchParams` config property)
- Updated dependencies
- @backstage/backend-plugin-api@1.6.0
- @backstage/config@1.3.6
- @backstage/types@1.2.2
- @backstage/plugin-auth-backend@0.25.7
- @backstage/plugin-auth-node@0.6.10
## @backstage/plugin-catalog-backend@3.3.1-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-openapi-utils@0.6.5-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/catalog-client@1.12.1
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/integration@1.19.0
- @backstage/types@1.2.2
- @backstage/plugin-catalog-common@1.1.7
- @backstage/plugin-catalog-node@1.20.1
- @backstage/plugin-events-node@0.4.18
- @backstage/plugin-permission-common@0.9.3
- @backstage/plugin-permission-node@0.10.7
## @backstage/plugin-catalog-backend-module-aws@0.4.19-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/integration@1.19.0
- @backstage/integration-aws-node@0.1.19
- @backstage/plugin-catalog-common@1.1.7
- @backstage/plugin-catalog-node@1.20.1
- @backstage/plugin-kubernetes-common@0.9.9
## @backstage/plugin-catalog-backend-module-backstage-openapi@0.5.10-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-openapi-utils@0.6.5-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/plugin-catalog-node@1.20.1
## @backstage/plugin-catalog-backend-module-gitlab@0.7.7-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/integration@1.19.0
- @backstage/plugin-catalog-common@1.1.7
- @backstage/plugin-catalog-node@1.20.1
- @backstage/plugin-events-node@0.4.18
## @backstage/plugin-catalog-backend-module-gitlab-org@0.2.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-plugin-api@1.6.0
- @backstage/plugin-catalog-backend-module-gitlab@0.7.7-next.0
- @backstage/plugin-catalog-node@1.20.1
- @backstage/plugin-events-node@0.4.18
## @backstage/plugin-catalog-backend-module-incremental-ingestion@0.7.8-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/types@1.2.2
- @backstage/plugin-catalog-backend@3.3.1-next.0
- @backstage/plugin-catalog-node@1.20.1
- @backstage/plugin-events-node@0.4.18
- @backstage/plugin-permission-common@0.9.3
## @backstage/plugin-catalog-backend-module-logs@0.1.18-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-plugin-api@1.6.0
- @backstage/plugin-catalog-backend@3.3.1-next.0
- @backstage/plugin-events-node@0.4.18
## @backstage/plugin-devtools-backend@0.5.13-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/cli-common@0.1.16
- @backstage/config@1.3.6
- @backstage/config-loader@1.10.7
- @backstage/errors@1.2.7
- @backstage/types@1.2.2
- @backstage/plugin-devtools-common@0.1.20
- @backstage/plugin-permission-common@0.9.3
- @backstage/plugin-permission-node@0.10.7
## @backstage/plugin-events-backend@0.5.10-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-openapi-utils@0.6.5-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/types@1.2.2
- @backstage/plugin-events-node@0.4.18
## @backstage/plugin-mcp-actions-backend@0.1.7-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/catalog-client@1.12.1
- @backstage/errors@1.2.7
- @backstage/types@1.2.2
- @backstage/plugin-catalog-node@1.20.1
## @backstage/plugin-mui-to-bui@0.2.3-next.0
### Patch Changes
- e4a1180: Updated tokens from `--bui-bg` to `--bui-bg-surface-0`
- Updated dependencies
- @backstage/ui@0.11.0-next.0
- @backstage/core-plugin-api@1.12.1
- @backstage/frontend-plugin-api@0.13.2
- @backstage/theme@0.7.1
## @backstage/plugin-scaffolder-backend@3.1.1-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-openapi-utils@0.6.5-next.0
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/integration@1.19.0
- @backstage/types@1.2.2
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-bitbucket-cloud-common@0.3.5
- @backstage/plugin-catalog-backend-module-scaffolder-entity-model@0.2.15
- @backstage/plugin-catalog-node@1.20.1
- @backstage/plugin-events-node@0.4.18
- @backstage/plugin-permission-common@0.9.3
- @backstage/plugin-permission-node@0.10.7
- @backstage/plugin-scaffolder-backend-module-azure@0.2.16
- @backstage/plugin-scaffolder-backend-module-bitbucket@0.3.17
- @backstage/plugin-scaffolder-backend-module-bitbucket-cloud@0.3.0
- @backstage/plugin-scaffolder-backend-module-bitbucket-server@0.2.16
- @backstage/plugin-scaffolder-backend-module-gerrit@0.2.16
- @backstage/plugin-scaffolder-backend-module-gitea@0.2.16
- @backstage/plugin-scaffolder-backend-module-github@0.9.3
- @backstage/plugin-scaffolder-backend-module-gitlab@0.11.0
- @backstage/plugin-scaffolder-common@1.7.4
- @backstage/plugin-scaffolder-node@0.12.2
## @backstage/plugin-scaffolder-backend-module-cookiecutter@0.3.19-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/integration@1.19.0
- @backstage/types@1.2.2
- @backstage/plugin-scaffolder-node@0.12.2
## @backstage/plugin-scaffolder-backend-module-yeoman@0.4.18-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-plugin-api@1.6.0
- @backstage/types@1.2.2
- @backstage/plugin-scaffolder-node@0.12.2
- @backstage/plugin-scaffolder-node-test-utils@0.3.7-next.0
## @backstage/plugin-scaffolder-node-test-utils@0.3.7-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-plugin-api@1.6.0
- @backstage/backend-test-utils@1.10.3-next.0
- @backstage/types@1.2.2
- @backstage/plugin-scaffolder-node@0.12.2
## @backstage/plugin-search-backend@2.0.10-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-openapi-utils@0.6.5-next.0
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/types@1.2.2
- @backstage/plugin-permission-common@0.9.3
- @backstage/plugin-permission-node@0.10.7
- @backstage/plugin-search-backend-node@1.4.0
- @backstage/plugin-search-common@1.2.21
## @backstage/plugin-techdocs-backend@2.1.4-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/catalog-client@1.12.1
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/errors@1.2.7
- @backstage/integration@1.19.0
- @backstage/types@1.2.2
- @backstage/plugin-catalog-node@1.20.1
- @backstage/plugin-techdocs-node@1.13.10
## @backstage/plugin-user-settings-backend@0.3.10-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/errors@1.2.7
- @backstage/types@1.2.2
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-signals-node@0.1.27
- @backstage/plugin-user-settings-common@0.0.1
## example-app@0.2.117-next.0
### Patch Changes
- Updated dependencies
- @backstage/ui@0.11.0-next.0
- @backstage/cli@0.35.2-next.0
- @backstage/plugin-mui-to-bui@0.2.3-next.0
- @backstage/app-defaults@1.7.3
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/core-app-api@1.19.3
- @backstage/core-components@0.18.4
- @backstage/core-plugin-api@1.12.1
- @backstage/frontend-app-api@0.13.3
- @backstage/integration-react@1.2.13
- @backstage/theme@0.7.1
- @backstage/plugin-api-docs@0.13.2
- @backstage/plugin-auth-react@0.1.22
- @backstage/plugin-catalog@1.32.1
- @backstage/plugin-catalog-common@1.1.7
- @backstage/plugin-catalog-graph@0.5.4
- @backstage/plugin-catalog-import@0.13.8
- @backstage/plugin-catalog-react@1.21.4
- @backstage/plugin-catalog-unprocessed-entities@0.2.24
- @backstage/plugin-devtools@0.1.34
- @backstage/plugin-home@0.8.15
- @backstage/plugin-kubernetes@0.12.14
- @backstage/plugin-kubernetes-cluster@0.0.32
- @backstage/plugin-notifications@0.5.12
- @backstage/plugin-org@0.6.47
- @backstage/plugin-permission-react@0.4.39
- @backstage/plugin-scaffolder@1.35.0
- @backstage/plugin-scaffolder-react@1.19.4
- @backstage/plugin-search@1.5.1
- @backstage/plugin-search-common@1.2.21
- @backstage/plugin-search-react@1.10.1
- @backstage/plugin-signals@0.0.26
- @backstage/plugin-techdocs@1.16.1
- @backstage/plugin-techdocs-module-addons-contrib@1.1.31
- @backstage/plugin-techdocs-react@1.3.6
- @backstage/plugin-user-settings@0.8.30
## example-app-next@0.0.31-next.0
### Patch Changes
- Updated dependencies
- @backstage/ui@0.11.0-next.0
- @backstage/cli@0.35.2-next.0
- @backstage/plugin-app-visualizer@0.1.27-next.0
- @backstage/app-defaults@1.7.3
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/core-app-api@1.19.3
- @backstage/core-compat-api@0.5.5
- @backstage/core-components@0.18.4
- @backstage/core-plugin-api@1.12.1
- @backstage/frontend-app-api@0.13.3
- @backstage/frontend-defaults@0.3.4
- @backstage/frontend-plugin-api@0.13.2
- @backstage/integration-react@1.2.13
- @backstage/theme@0.7.1
- @backstage/plugin-api-docs@0.13.2
- @backstage/plugin-app@0.3.3
- @backstage/plugin-auth@0.1.3
- @backstage/plugin-auth-react@0.1.22
- @backstage/plugin-catalog@1.32.1
- @backstage/plugin-catalog-common@1.1.7
- @backstage/plugin-catalog-graph@0.5.4
- @backstage/plugin-catalog-import@0.13.8
- @backstage/plugin-catalog-react@1.21.4
- @backstage/plugin-catalog-unprocessed-entities@0.2.24
- @backstage/plugin-home@0.8.15
- @backstage/plugin-kubernetes@0.12.14
- @backstage/plugin-kubernetes-cluster@0.0.32
- @backstage/plugin-notifications@0.5.12
- @backstage/plugin-org@0.6.47
- @backstage/plugin-permission-react@0.4.39
- @backstage/plugin-scaffolder@1.35.0
- @backstage/plugin-scaffolder-react@1.19.4
- @backstage/plugin-search@1.5.1
- @backstage/plugin-search-common@1.2.21
- @backstage/plugin-search-react@1.10.1
- @backstage/plugin-signals@0.0.26
- @backstage/plugin-techdocs@1.16.1
- @backstage/plugin-techdocs-module-addons-contrib@1.1.31
- @backstage/plugin-techdocs-react@1.3.6
- @backstage/plugin-user-settings@0.8.30
## example-backend@0.0.46-next.0
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.0
- @backstage/backend-plugin-api@1.6.0
- @backstage/catalog-model@1.7.6
- @backstage/plugin-app-backend@0.5.9
- @backstage/plugin-auth-backend@0.25.7
- @backstage/plugin-auth-backend-module-github-provider@0.4.0
- @backstage/plugin-auth-backend-module-guest-provider@0.2.15
- @backstage/plugin-auth-backend-module-openshift-provider@0.1.3
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-catalog-backend@3.3.1-next.0
- @backstage/plugin-catalog-backend-module-backstage-openapi@0.5.10-next.0
- @backstage/plugin-catalog-backend-module-openapi@0.2.17
- @backstage/plugin-catalog-backend-module-scaffolder-entity-model@0.2.15
- @backstage/plugin-catalog-backend-module-unprocessed@0.6.7
- @backstage/plugin-devtools-backend@0.5.13-next.0
- @backstage/plugin-events-backend@0.5.10-next.0
- @backstage/plugin-events-backend-module-google-pubsub@0.1.7
- @backstage/plugin-kubernetes-backend@0.21.0
- @backstage/plugin-mcp-actions-backend@0.1.7-next.0
- @backstage/plugin-notifications-backend@0.6.1
- @backstage/plugin-permission-backend@0.7.7
- @backstage/plugin-permission-backend-module-allow-all-policy@0.2.15
- @backstage/plugin-permission-common@0.9.3
- @backstage/plugin-permission-node@0.10.7
- @backstage/plugin-proxy-backend@0.6.9
- @backstage/plugin-scaffolder-backend@3.1.1-next.0
- @backstage/plugin-scaffolder-backend-module-github@0.9.3
- @backstage/plugin-scaffolder-backend-module-notifications@0.1.17
- @backstage/plugin-search-backend@2.0.10-next.0
- @backstage/plugin-search-backend-module-catalog@0.3.11
- @backstage/plugin-search-backend-module-elasticsearch@1.7.9
- @backstage/plugin-search-backend-module-explore@0.3.10
- @backstage/plugin-search-backend-module-techdocs@0.4.9
- @backstage/plugin-search-backend-node@1.4.0
- @backstage/plugin-signals-backend@0.3.11
- @backstage/plugin-techdocs-backend@2.1.4-next.0
## e2e-test@0.2.36-next.0
### Patch Changes
- Updated dependencies
- @backstage/create-app@0.7.8-next.0
- @backstage/cli-common@0.1.16
- @backstage/errors@1.2.7
## techdocs-cli-embedded-app@0.2.116-next.0
### Patch Changes
- Updated dependencies
- @backstage/ui@0.11.0-next.0
- @backstage/cli@0.35.2-next.0
- @backstage/app-defaults@1.7.3
- @backstage/catalog-model@1.7.6
- @backstage/config@1.3.6
- @backstage/core-app-api@1.19.3
- @backstage/core-components@0.18.4
- @backstage/core-plugin-api@1.12.1
- @backstage/integration-react@1.2.13
- @backstage/test-utils@1.7.14
- @backstage/theme@0.7.1
- @backstage/plugin-catalog@1.32.1
- @backstage/plugin-techdocs@1.16.1
- @backstage/plugin-techdocs-react@1.3.6
docs/releases/v1.47.0-next.1-changelog.md
+648
View File
@@ -0,0 +1,648 @@
# Release v1.47.0-next.1
Upgrade Helper: [https://backstage.github.io/upgrade-helper/?to=1.47.0-next.1](https://backstage.github.io/upgrade-helper/?to=1.47.0-next.1)
## @backstage/backend-defaults@0.14.1-next.1
### Patch Changes
- 3afeab4: Implementing `readTree` for `GoogleGcsReader`
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/backend-dynamic-feature-service@0.7.8-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.1
- @backstage/plugin-catalog-backend@3.3.1-next.1
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/cli@0.35.2-next.1
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/core-compat-api@0.5.6-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/create-app@0.7.8-next.1
### Patch Changes
- Bumped create-app version.
## @backstage/dev-utils@1.1.19-next.1
### Patch Changes
- Updated dependencies
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
## @backstage/frontend-app-api@0.13.4-next.0
### Patch Changes
- Updated dependencies
- @backstage/frontend-defaults@0.3.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/frontend-defaults@0.3.5-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-app@0.3.4-next.0
- @backstage/frontend-app-api@0.13.4-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/frontend-test-utils@0.4.3-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-app@0.3.4-next.0
- @backstage/frontend-app-api@0.13.4-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/integration@1.19.2-next.0
### Patch Changes
- 3afeab4: Implementing `ScmIntegration` for `GoogleGcs`
- 9083273: Rollback the lowercase replacing in GitHub integration config
## @backstage/integration-react@1.2.14-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @techdocs/cli@1.10.4-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.1
- @backstage/plugin-techdocs-node@1.13.11-next.0
## @backstage/plugin-api-docs@0.13.3-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog@1.32.2-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-app@0.3.4-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration-react@1.2.14-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-bitbucket-cloud-common@0.3.6-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog@1.32.2-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-scaffolder-common@1.7.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/core-compat-api@0.5.6-next.0
- @backstage/frontend-plugin-api@0.13.2
- @backstage/plugin-search-react@1.10.1
## @backstage/plugin-catalog-backend@3.3.1-next.1
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog-backend-module-aws@0.4.19-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.1
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog-backend-module-azure@0.3.13-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog-backend-module-bitbucket-cloud@0.5.7-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-bitbucket-cloud-common@0.3.6-next.0
## @backstage/plugin-catalog-backend-module-bitbucket-server@0.5.7-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog-backend-module-gerrit@0.3.10-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog-backend-module-gitea@0.1.8-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog-backend-module-github@0.12.1-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog-backend-module-github-org@0.3.18-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-backend-module-github@0.12.1-next.0
## @backstage/plugin-catalog-backend-module-gitlab@0.7.7-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.1
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog-backend-module-openapi@0.2.18-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-catalog-backend-module-scaffolder-entity-model@0.2.16-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-scaffolder-common@1.7.5-next.0
## @backstage/plugin-catalog-graph@0.5.5-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-catalog-import@0.13.9-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-catalog-react@1.21.5-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration-react@1.2.14-next.0
- @backstage/frontend-test-utils@0.4.3-next.0
- @backstage/core-compat-api@0.5.6-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-devtools@0.1.35-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-compat-api@0.5.6-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-events-backend-module-github@0.4.8-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-home@0.8.16-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-kubernetes@0.12.15-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-kubernetes-cluster@0.0.33-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.5-next.0
## @backstage/plugin-org@0.6.48-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-org-react@0.1.46-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.5-next.0
## @backstage/plugin-scaffolder@1.35.1-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-scaffolder-common@1.7.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/plugin-scaffolder-react@1.19.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-scaffolder-backend@3.1.1-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.1
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-bitbucket-cloud-common@0.3.6-next.0
- @backstage/plugin-scaffolder-backend-module-azure@0.2.17-next.0
- @backstage/plugin-scaffolder-backend-module-bitbucket@0.3.18-next.0
- @backstage/plugin-scaffolder-backend-module-bitbucket-cloud@0.3.1-next.0
- @backstage/plugin-scaffolder-backend-module-bitbucket-server@0.2.17-next.0
- @backstage/plugin-scaffolder-backend-module-gerrit@0.2.17-next.0
- @backstage/plugin-scaffolder-backend-module-gitea@0.2.17-next.0
- @backstage/plugin-scaffolder-backend-module-github@0.9.4-next.0
- @backstage/plugin-scaffolder-backend-module-gitlab@0.11.1-next.0
- @backstage/plugin-scaffolder-common@1.7.5-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
- @backstage/plugin-catalog-backend-module-scaffolder-entity-model@0.2.16-next.0
## @backstage/plugin-scaffolder-backend-module-azure@0.2.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-bitbucket@0.3.18-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-backend-module-bitbucket-cloud@0.3.1-next.0
- @backstage/plugin-scaffolder-backend-module-bitbucket-server@0.2.17-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-bitbucket-cloud@0.3.1-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-bitbucket-cloud-common@0.3.6-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-bitbucket-server@0.2.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-confluence-to-markdown@0.3.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-cookiecutter@0.3.19-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.1
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-gcp@0.2.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-gerrit@0.2.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-gitea@0.2.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-github@0.9.4-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-gitlab@0.11.1-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-notifications@0.1.18-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-rails@0.5.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-sentry@0.2.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-backend-module-yeoman@0.4.18-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-scaffolder-node@0.12.3-next.0
- @backstage/plugin-scaffolder-node-test-utils@0.3.7-next.1
## @backstage/plugin-scaffolder-common@1.7.5-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-scaffolder-node@0.12.3-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-scaffolder-common@1.7.5-next.0
## @backstage/plugin-scaffolder-node-test-utils@0.3.7-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-scaffolder-node@0.12.3-next.0
## @backstage/plugin-scaffolder-react@1.19.5-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-scaffolder-common@1.7.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-search@1.5.2-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
- @backstage/plugin-search-react@1.10.1
## @backstage/plugin-search-backend-module-techdocs@0.4.10-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-techdocs-node@1.13.11-next.0
## @backstage/plugin-techdocs@1.16.2-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
- @backstage/plugin-search-react@1.10.1
## @backstage/plugin-techdocs-addons-test-utils@2.0.1-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-techdocs@1.16.2-next.0
- @backstage/plugin-catalog@1.32.2-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/plugin-search-react@1.10.1
## @backstage/plugin-techdocs-backend@2.1.4-next.1
### Patch Changes
- b6ff2a5: Some AWS `publisher` config options such as `region`, `endpoint`, `accountId` are now marked as `@visibility backend` instead of `secret`.
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.1
- @backstage/integration@1.19.2-next.0
- @backstage/plugin-techdocs-node@1.13.11-next.0
## @backstage/plugin-techdocs-module-addons-contrib@1.1.32-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/frontend-plugin-api@0.13.2
## @backstage/plugin-techdocs-node@1.13.11-next.0
### Patch Changes
- Updated dependencies
- @backstage/integration@1.19.2-next.0
## @backstage/plugin-user-settings@0.8.31-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## example-app@0.2.117-next.1
### Patch Changes
- Updated dependencies
- @backstage/cli@0.35.2-next.1
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog-import@0.13.9-next.0
- @backstage/plugin-scaffolder@1.35.1-next.0
- @backstage/plugin-techdocs@1.16.2-next.0
- @backstage/plugin-techdocs-module-addons-contrib@1.1.32-next.0
- @backstage/plugin-catalog@1.32.2-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/plugin-scaffolder-react@1.19.5-next.0
- @backstage/frontend-app-api@0.13.4-next.0
- @backstage/plugin-api-docs@0.13.3-next.0
- @backstage/plugin-catalog-graph@0.5.5-next.0
- @backstage/plugin-org@0.6.48-next.0
- @backstage/plugin-user-settings@0.8.31-next.0
- @backstage/plugin-home@0.8.16-next.0
- @backstage/plugin-kubernetes@0.12.15-next.0
- @backstage/plugin-kubernetes-cluster@0.0.33-next.0
- @backstage/plugin-search@1.5.2-next.0
- @backstage/plugin-search-react@1.10.1
- @backstage/plugin-devtools@0.1.35-next.0
## example-app-next@0.0.31-next.1
### Patch Changes
- Updated dependencies
- @backstage/cli@0.35.2-next.1
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog-import@0.13.9-next.0
- @backstage/plugin-scaffolder@1.35.1-next.0
- @backstage/plugin-techdocs@1.16.2-next.0
- @backstage/plugin-techdocs-module-addons-contrib@1.1.32-next.0
- @backstage/plugin-app@0.3.4-next.0
- @backstage/plugin-catalog@1.32.2-next.0
- @backstage/plugin-catalog-react@1.21.5-next.0
- @backstage/plugin-scaffolder-react@1.19.5-next.0
- @backstage/frontend-app-api@0.13.4-next.0
- @backstage/frontend-defaults@0.3.5-next.0
- @backstage/core-compat-api@0.5.6-next.0
- @backstage/plugin-api-docs@0.13.3-next.0
- @backstage/plugin-catalog-graph@0.5.5-next.0
- @backstage/plugin-org@0.6.48-next.0
- @backstage/plugin-user-settings@0.8.31-next.0
- @backstage/plugin-home@0.8.16-next.0
- @backstage/plugin-kubernetes@0.12.15-next.0
- @backstage/plugin-kubernetes-cluster@0.0.33-next.0
- @backstage/plugin-search@1.5.2-next.0
- @backstage/plugin-app-visualizer@0.1.27-next.0
- @backstage/plugin-auth@0.1.3
- @backstage/frontend-plugin-api@0.13.2
- @backstage/plugin-search-react@1.10.1
## example-backend@0.0.46-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.14.1-next.1
- @backstage/plugin-techdocs-backend@2.1.4-next.1
- @backstage/plugin-catalog-backend@3.3.1-next.1
- @backstage/plugin-catalog-backend-module-openapi@0.2.18-next.0
- @backstage/plugin-scaffolder-backend@3.1.1-next.1
- @backstage/plugin-scaffolder-backend-module-github@0.9.4-next.0
- @backstage/plugin-catalog-backend-module-scaffolder-entity-model@0.2.16-next.0
- @backstage/plugin-scaffolder-backend-module-notifications@0.1.18-next.0
- @backstage/plugin-search-backend-module-techdocs@0.4.10-next.0
## @internal/scaffolder@0.0.17-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-scaffolder-react@1.19.5-next.0
- @backstage/frontend-plugin-api@0.13.2
## techdocs-cli-embedded-app@0.2.116-next.1
### Patch Changes
- Updated dependencies
- @backstage/cli@0.35.2-next.1
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-techdocs@1.16.2-next.0
- @backstage/plugin-catalog@1.32.2-next.0
docs/releases/v1.47.0-next.2-changelog.md
+385
View File
@@ -0,0 +1,385 @@
# Release v1.47.0-next.2
Upgrade Helper: [https://backstage.github.io/upgrade-helper/?to=1.47.0-next.2](https://backstage.github.io/upgrade-helper/?to=1.47.0-next.2)
## @backstage/app-defaults@1.7.4-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/core-components@0.18.5-next.0
### Patch Changes
- a723b8a: The MarkdownContent component now handles HTML content the same way as GitHub when rendering GitHub-flavored Markdown
## @backstage/create-app@0.7.8-next.2
### Patch Changes
- f1fe6fe: Updated Dockerfile to use Node 24 and Debian Trixie
## @backstage/dev-utils@1.1.19-next.2
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/app-defaults@1.7.4-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
## @backstage/frontend-defaults@0.3.5-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-app@0.3.4-next.1
## @backstage/plugin-api-docs@0.13.3-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog@1.32.2-next.1
- @backstage/plugin-catalog-react@1.21.5-next.1
## @backstage/plugin-app@0.3.4-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/integration-react@1.2.14-next.0
## @backstage/plugin-app-visualizer@0.1.27-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-auth@0.1.4-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-auth-react@0.1.23-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-catalog@1.32.2-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-search-react@1.10.2-next.0
- @backstage/plugin-techdocs-react@1.3.7-next.0
## @backstage/plugin-catalog-graph@0.5.5-next.1
### Patch Changes
- 5c49a00: Update for the `qs` library bump: the old array limit setting has changed to be more strict; you can no longer just give a zero to mean unlimited. So we choose an arbitrary high value, to at least go higher than the default 20.
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
## @backstage/plugin-catalog-import@0.13.9-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
## @backstage/plugin-catalog-react@1.21.5-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/integration-react@1.2.14-next.0
## @backstage/plugin-catalog-unprocessed-entities@0.2.25-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-config-schema@0.1.76-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-devtools@0.1.35-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-home@0.8.16-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-home-react@0.1.34-next.0
## @backstage/plugin-home-react@0.1.34-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-kubernetes@0.12.15-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-kubernetes-react@0.5.15-next.0
## @backstage/plugin-kubernetes-cluster@0.0.33-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-kubernetes-react@0.5.15-next.0
## @backstage/plugin-kubernetes-react@0.5.15-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-notifications@0.5.13-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-org@0.6.48-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
## @backstage/plugin-org-react@0.1.46-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
## @backstage/plugin-scaffolder@1.35.1-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-scaffolder-react@1.19.5-next.1
- @backstage/plugin-techdocs-react@1.3.7-next.0
## @backstage/plugin-scaffolder-react@1.19.5-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
## @backstage/plugin-search@1.5.2-next.1
### Patch Changes
- 5c49a00: Update for the `qs` library bump: the old array limit setting has changed to be more strict; you can no longer just give a zero to mean unlimited. So we choose an arbitrary high value, to at least go higher than the default 20.
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-search-react@1.10.2-next.0
## @backstage/plugin-search-react@1.10.2-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-signals@0.0.27-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-techdocs@1.16.2-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-auth-react@0.1.23-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-search-react@1.10.2-next.0
- @backstage/plugin-techdocs-react@1.3.7-next.0
## @backstage/plugin-techdocs-addons-test-utils@2.0.1-next.1
### Patch Changes
- Updated dependencies
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog@1.32.2-next.1
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-search-react@1.10.2-next.0
- @backstage/plugin-techdocs@1.16.2-next.1
- @backstage/plugin-techdocs-react@1.3.7-next.0
## @backstage/plugin-techdocs-module-addons-contrib@1.1.32-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-techdocs-react@1.3.7-next.0
## @backstage/plugin-techdocs-react@1.3.7-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## @backstage/plugin-user-settings@0.8.31-next.1
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-react@1.21.5-next.1
## example-app@0.2.117-next.2
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-graph@0.5.5-next.1
- @backstage/plugin-search@1.5.2-next.1
- @backstage/app-defaults@1.7.4-next.0
- @backstage/cli@0.35.2-next.1
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-api-docs@0.13.3-next.1
- @backstage/plugin-auth-react@0.1.23-next.0
- @backstage/plugin-catalog@1.32.2-next.1
- @backstage/plugin-catalog-import@0.13.9-next.1
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-catalog-unprocessed-entities@0.2.25-next.0
- @backstage/plugin-devtools@0.1.35-next.1
- @backstage/plugin-home@0.8.16-next.1
- @backstage/plugin-kubernetes@0.12.15-next.1
- @backstage/plugin-kubernetes-cluster@0.0.33-next.1
- @backstage/plugin-notifications@0.5.13-next.0
- @backstage/plugin-org@0.6.48-next.1
- @backstage/plugin-scaffolder@1.35.1-next.1
- @backstage/plugin-scaffolder-react@1.19.5-next.1
- @backstage/plugin-search-react@1.10.2-next.0
- @backstage/plugin-signals@0.0.27-next.0
- @backstage/plugin-techdocs@1.16.2-next.1
- @backstage/plugin-techdocs-module-addons-contrib@1.1.32-next.1
- @backstage/plugin-techdocs-react@1.3.7-next.0
- @backstage/plugin-user-settings@0.8.31-next.1
## example-app-next@0.0.31-next.2
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/plugin-catalog-graph@0.5.5-next.1
- @backstage/plugin-search@1.5.2-next.1
- @backstage/app-defaults@1.7.4-next.0
- @backstage/cli@0.35.2-next.1
- @backstage/frontend-defaults@0.3.5-next.1
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-api-docs@0.13.3-next.1
- @backstage/plugin-app@0.3.4-next.1
- @backstage/plugin-app-visualizer@0.1.27-next.1
- @backstage/plugin-auth@0.1.4-next.0
- @backstage/plugin-auth-react@0.1.23-next.0
- @backstage/plugin-catalog@1.32.2-next.1
- @backstage/plugin-catalog-import@0.13.9-next.1
- @backstage/plugin-catalog-react@1.21.5-next.1
- @backstage/plugin-catalog-unprocessed-entities@0.2.25-next.0
- @backstage/plugin-home@0.8.16-next.1
- @backstage/plugin-kubernetes@0.12.15-next.1
- @backstage/plugin-kubernetes-cluster@0.0.33-next.1
- @backstage/plugin-notifications@0.5.13-next.0
- @backstage/plugin-org@0.6.48-next.1
- @backstage/plugin-scaffolder@1.35.1-next.1
- @backstage/plugin-scaffolder-react@1.19.5-next.1
- @backstage/plugin-search-react@1.10.2-next.0
- @backstage/plugin-signals@0.0.27-next.0
- @backstage/plugin-techdocs@1.16.2-next.1
- @backstage/plugin-techdocs-module-addons-contrib@1.1.32-next.1
- @backstage/plugin-techdocs-react@1.3.7-next.0
- @backstage/plugin-user-settings@0.8.31-next.1
## app-next-example-plugin@0.0.31-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
## techdocs-cli-embedded-app@0.2.116-next.2
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
- @backstage/app-defaults@1.7.4-next.0
- @backstage/cli@0.35.2-next.1
- @backstage/integration-react@1.2.14-next.0
- @backstage/plugin-catalog@1.32.2-next.1
- @backstage/plugin-techdocs@1.16.2-next.1
- @backstage/plugin-techdocs-react@1.3.7-next.0
## @internal/plugin-todo-list@1.0.47-next.0
### Patch Changes
- Updated dependencies
- @backstage/core-components@0.18.5-next.0
docs/releases/v1.47.0-next.3-changelog.md
+365
View File
@@ -0,0 +1,365 @@
# Release v1.47.0-next.3
Upgrade Helper: [https://backstage.github.io/upgrade-helper/?to=1.47.0-next.3](https://backstage.github.io/upgrade-helper/?to=1.47.0-next.3)
## @backstage/backend-defaults@0.15.0-next.2
### Minor Changes
- 6fc00e6: Added action filtering support with glob patterns and attribute constraints.
The `ActionsService` now supports filtering actions based on configuration. This allows controlling which actions are exposed to consumers like the MCP backend.
Configuration example:
```yaml
backend:
actions:
pluginSources:
- catalog
- scaffolder
filter:
include:
- id: 'catalog:*'
attributes:
destructive: false
- id: 'scaffolder:*'
exclude:
- id: '*:delete-*'
- attributes:
readOnly: false
```
Filtering logic:
- `include`: Rules for actions to include. Each rule can specify an `id` glob pattern and/or `attributes` constraints. An action must match at least one rule to be included. If no include rules are specified, all actions are included by default.
- `exclude`: Rules for actions to exclude. Takes precedence over include rules.
- Each rule combines `id` and `attributes` with AND logic (both must match if specified).
### Patch Changes
- Updated dependencies
- @backstage/backend-app-api@1.4.0
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-permission-node@0.10.7
## @backstage/ui@0.11.0-next.1
### Minor Changes
- 243e5e7: **BREAKING**: Redesigned Table component with new `useTable` hook API.
- The `Table` component (React Aria wrapper) is renamed to `TableRoot`
- New high-level `Table` component that handles data display, pagination, sorting, and selection
- The `useTable` hook is completely redesigned with a new API supporting three pagination modes (complete, offset, cursor)
- New types: `ColumnConfig`, `TableProps`, `TableItem`, `UseTableOptions`, `UseTableResult`
New features include unified pagination modes, debounced query changes, stale data preservation during reloads, and row selection with toggle/replace behaviors.
**Migration guide:**
1. Update imports and use the new `useTable` hook:
```diff
-import { Table, useTable } from '@backstage/ui';
-const { data, paginationProps } = useTable({ data: items, pagination: {...} });
+import { Table, useTable, type ColumnConfig } from '@backstage/ui';
+const { tableProps } = useTable({
+ mode: 'complete',
+ getData: () => items,
+});
```
2. Define columns and render with the new Table API:
```diff
-<Table aria-label="My table">
- <TableHeader>...</TableHeader>
- <TableBody items={data}>...</TableBody>
-</Table>
-<TablePagination {...paginationProps} />
+const columns: ColumnConfig<Item>[] = [
+ { id: 'name', label: 'Name', isRowHeader: true, cell: item => <CellText title={item.name} /> },
+ { id: 'type', label: 'Type', cell: item => <CellText title={item.type} /> },
+];
+
+<Table columnConfig={columns} {...tableProps} />
```
Affected components: Table, TableRoot, TablePagination
- 95246eb: **Breaking** Updating color tokens to match the new neutral style on different surfaces.
## Migration notes
There's no direct replacement for the old tint tokens but you can use the new neutral set of color tokens on surface 0 or 1 as a replacement.
- `--bui-bg-tint` can be replaced by `--bui-bg-neutral-on-surface-0`
- `--bui-bg-tint-hover` can be replaced by `--bui-bg-neutral-on-surface-0-hover`
- `--bui-bg-tint-pressed` can be replaced by `--bui-bg-neutral-on-surface-0-pressed`
- `--bui-bg-tint-disabled` can be replaced by `--bui-bg-neutral-on-surface-0-disabled`
- ea0c6d8: Introduce new `ToggleButton` & `ToggleButtonGroup` components in Backstage UI
### Patch Changes
- 21c87cc: Fixes disabled state in primary and secondary buttons in Backstage UI.
- b3253b6: Fixed `Link` component causing hard page refreshes for internal routes. The component now properly uses React Router's navigation instead of full page reloads.
## @backstage/plugin-auth-backend@0.26.0-next.0
### Minor Changes
- 7ffc873: Fix `user_created_at` migration causing `SQLiteError` regarding use of non-constants for defaults
### Patch Changes
- Updated dependencies
- @backstage/plugin-auth-node@0.6.10
## @backstage/plugin-events-backend-module-kafka@0.3.0-next.0
### Minor Changes
- ef5bbd8: Add support for Kafka offset configuration (`fromBeginning`) and `autoCommit`
## @backstage/plugin-home@0.9.0-next.2
### Minor Changes
- e091a83: Widget configurations are now only saved to storage when the Save button is explicitly clicked. Added a Cancel button that allows users to discard unsaved changes and revert to the last saved state.
## @backstage/backend-dynamic-feature-service@0.7.8-next.2
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-catalog-backend@3.3.1-next.1
- @backstage/plugin-events-backend@0.5.10-next.0
- @backstage/plugin-permission-node@0.10.7
- @backstage/plugin-search-backend-node@1.4.0
## @backstage/backend-test-utils@1.10.3-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
- @backstage/backend-app-api@1.4.0
- @backstage/plugin-auth-node@0.6.10
## @backstage/create-app@0.7.8-next.3
### Patch Changes
- Bumped create-app version.
## @techdocs/cli@1.10.4-next.2
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
## @backstage/plugin-api-docs@0.13.3-next.2
### Patch Changes
- 0216090: Updated dependency `@types/swagger-ui-react` to `^5.0.0`.
- abeba2b: Fix types with new bumped dependency
- Updated dependencies
- @backstage/plugin-catalog@1.32.2-next.2
## @backstage/plugin-auth-backend-module-aws-alb-provider@0.4.11-next.0
### Patch Changes
- Updated dependencies
- @backstage/plugin-auth-backend@0.26.0-next.0
- @backstage/plugin-auth-node@0.6.10
## @backstage/plugin-auth-backend-module-oidc-provider@0.4.11-next.1
### Patch Changes
- Updated dependencies
- @backstage/plugin-auth-backend@0.26.0-next.0
- @backstage/plugin-auth-node@0.6.10
## @backstage/plugin-catalog@1.32.2-next.2
### Patch Changes
- 7ca91e8: Header in EntityLayout should always be shown.
Monitoring the loading status caused flickering when the refresh() method of the Async Entity was invoked.
## @backstage/plugin-catalog-backend-module-aws@0.4.19-next.2
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
## @backstage/plugin-catalog-backend-module-github@0.12.1-next.1
### Patch Changes
- cb4b907: Improved efficiency of `GithubOrgEntityProvider` membership event handling and edit team. The provider now fetches only the specific user's teams instead of all organization users when processing membership events, and uses `addEntitiesOperation` instead of `replaceEntitiesOperation` to avoid unnecessary entity deletions.
## @backstage/plugin-catalog-backend-module-gitlab@0.7.7-next.2
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
## @backstage/plugin-catalog-backend-module-incremental-ingestion@0.7.8-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
- @backstage/plugin-catalog-backend@3.3.1-next.1
## @backstage/plugin-catalog-backend-module-puppetdb@0.2.18-next.0
### Patch Changes
- a307700: Fixed crash when `latest_report_status` is undefined
## @backstage/plugin-devtools-backend@0.5.13-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
- @backstage/plugin-permission-node@0.10.7
## @backstage/plugin-mcp-actions-backend@0.1.7-next.1
### Patch Changes
- 4d82a35: build(deps): bump `@modelcontextprotocol/sdk` from 1.24.3 to 1.25.2
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
## @backstage/plugin-scaffolder@1.35.1-next.2
### Patch Changes
- 9d75495: Fixed bug in RepoUrlPickerComponent component where repository names were not being autocompleted.
## @backstage/plugin-scaffolder-backend@3.1.1-next.2
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
- @backstage/plugin-scaffolder-backend-module-github@0.9.4-next.1
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-permission-node@0.10.7
## @backstage/plugin-scaffolder-backend-module-cookiecutter@0.3.19-next.2
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
## @backstage/plugin-scaffolder-backend-module-github@0.9.4-next.1
### Patch Changes
- bb7088b: Added options to set [workflow access level][access-level] for repositories to `github:repo:create`
This is useful when creating repositories for GitHub Actions to manage access
to the workflows during creation.
```diff
- action: github:repo:create
id: create-repo
input:
repoUrl: github.com?owner=owner&repo=repo
visibility: private
+ workflowAccess: organization
```
[access-level]: https://docs.github.com/en/rest/actions/permissions?apiVersion=2022-11-28#set-the-level-of-access-for-workflows-outside-of-the-repository
## @backstage/plugin-search-backend@2.0.10-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
- @backstage/plugin-permission-node@0.10.7
- @backstage/plugin-search-backend-node@1.4.0
## @backstage/plugin-techdocs-backend@2.1.4-next.2
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
## @backstage/plugin-user-settings-backend@0.3.10-next.1
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
- @backstage/plugin-auth-node@0.6.10
## example-app@0.2.117-next.3
### Patch Changes
- Updated dependencies
- @backstage/ui@0.11.0-next.1
- @backstage/plugin-catalog@1.32.2-next.2
- @backstage/plugin-home@0.9.0-next.2
- @backstage/plugin-api-docs@0.13.3-next.2
- @backstage/plugin-scaffolder@1.35.1-next.2
- @backstage/cli@0.35.2-next.1
## example-app-next@0.0.31-next.3
### Patch Changes
- Updated dependencies
- @backstage/ui@0.11.0-next.1
- @backstage/plugin-catalog@1.32.2-next.2
- @backstage/plugin-home@0.9.0-next.2
- @backstage/plugin-api-docs@0.13.3-next.2
- @backstage/plugin-scaffolder@1.35.1-next.2
- @backstage/cli@0.35.2-next.1
## example-backend@0.0.46-next.2
### Patch Changes
- Updated dependencies
- @backstage/backend-defaults@0.15.0-next.2
- @backstage/plugin-mcp-actions-backend@0.1.7-next.1
- @backstage/plugin-auth-backend@0.26.0-next.0
- @backstage/plugin-scaffolder-backend-module-github@0.9.4-next.1
- @backstage/plugin-app-backend@0.5.9
- @backstage/plugin-auth-backend-module-github-provider@0.4.0
- @backstage/plugin-auth-backend-module-openshift-provider@0.1.3
- @backstage/plugin-auth-node@0.6.10
- @backstage/plugin-catalog-backend@3.3.1-next.1
- @backstage/plugin-devtools-backend@0.5.13-next.1
- @backstage/plugin-events-backend@0.5.10-next.0
- @backstage/plugin-events-backend-module-google-pubsub@0.1.7
- @backstage/plugin-kubernetes-backend@0.21.0
- @backstage/plugin-notifications-backend@0.6.1
- @backstage/plugin-permission-backend@0.7.7
- @backstage/plugin-permission-node@0.10.7
- @backstage/plugin-proxy-backend@0.6.9
- @backstage/plugin-scaffolder-backend@3.1.1-next.2
- @backstage/plugin-search-backend@2.0.10-next.1
- @backstage/plugin-search-backend-node@1.4.0
- @backstage/plugin-signals-backend@0.3.11
- @backstage/plugin-techdocs-backend@2.1.4-next.2
docs/releases/v1.47.0.md
+128
View File
@@ -0,0 +1,128 @@
---
id: v1.47.0
title: v1.47.0
description: Backstage Release v1.47.0
---
These are the release notes for the v1.47.0 release of [Backstage](https://backstage.io/).
A huge thanks to the whole team of maintainers and contributors as well as the amazing Backstage Community for the hard work in getting this release developed and done.
## Highlights
### BREAKING: Redesigned `Table` and `useTable` in `@backstage/ui`
The `Table` component and accompanying `useTable` hook have been redesigned. The low-level React Aria wrapper `Table` is now `TableRoot`, while a higher level `Table` component now handles pagination, sorting, selection, and data display. The `useTable` also has a new API, that supports 3 pagination modes: `complete`, `offset`, and `cursor`.
More information along with a migration guide can be found in the [BUI Changelog](https://ui.backstage.io/changelog).
### BREAKING: Updated color tokens in `@backstage/ui`
UI color tokens have been updated to align with the new neutral surface-based design system, and the `-tint` tokens have been removed.
More information can be found in the [BUI Changelog](https://ui.backstage.io/changelog).
### BREAKING: Redirect validation in the URL reader
`coreServices.urlReader` now validates that redirect chains are subject to the allow list in `backend.reading.allow` of your app config. If you were relying on redirects that pointed to URLs that were not allowlisted, you will now have to add those to your config as well.
To support this, the `FetchUrlReader` class no longer has a public constructor, but instead has a `fromConfig` static factory method.
### BREAKING: Better AWS S3 auth handling in techdocs
Techdocs now knows how to properly use `integrations.awsS3` config to authenticate with AWS S3. Since this affects the priority order of which auth setting is being used, it’s technically a breaking change.
The new priority is:
1. `aws.accounts`
2. `techdocs.publisher.awsS3.credentials`
3. `integrations.awsS3`
4. Default credential chain
### Deprecation and upcoming restrictions of blueprints for app customization in `@backstage/frontend-plugin-api`
There were several blueprints in `@backstage/frontend-plugin-api` that were intended only for use in customization of the central app. For example `SignInPageBlueprint` that replaces the sign-in page, or `NavContentBlueprint` that replaces the sidebar content. The following blueprints have all been deprecated and moved to a new `@backstage/plugin-app-react` package:
- `IconBundleBlueprint`
- `NavContentBlueprint`
- `RouterBlueprint`
- `SignInPageBlueprint`
- `SwappableComponentBlueprint`
- `ThemeBlueprint`
- `TranslationBlueprint`
These blueprints are also being restricted from use outside of the `app` plugin. This means that you have to either use an `app` plugin override or a module with `pluginId` set to `app`. These currently trigger deprecation warnings, but will instead be rejected in a future release.
### Deprecations and upcoming restrictions for API factories in new frontend system
Similar to the above change, restrictions are being introduced that limit the ability for plugins to override both core Utility APIs and API factories from other plugins. Plugins will be restricted from installing factory overrides for Utility APIs that belong to other plugins. This restriction also applies to the core APIs provided by the app plugin. These overrides now instead need to be made using a plugin override or module.
Just like the blueprint changes, this release will only trigger deprecation warnings, with the change taking effect in a future release.
### Backend action filtering support
`ActionsService` in `@backstage/backend-defaults` now supports action filtering based on configuration to enable control over which actions are exposed to consumers like the MCP backend.
At the time of writing, this is primarily documented in [the relevant configuration schema](https://github.com/backstage/backstage/blob/master/packages/backend-defaults/config.d.ts).
### `scaffolder` now supports configuration for `workflowAccess` level for creating Github repositories
Workflow files can now configure the level of access to Github Actions for workflows outside of a repository.
This is useful when creating repositories for GitHub Actions to manage access to the workflows for `github:repo:create`.
```diff
- action: github:repo:create
id: create-repo
input:
repoUrl: github.com?owner=owner&repo=repo
visibility: private
+ workflowAccess: organization
```
Github Actions access-level documentation can be found [here](https://docs.github.com/en/rest/actions/permissions?apiVersion=2022-11-28#set-the-level-of-access-for-workflows-outside-of-the-repository).
Contributed by [@fearphage](https://github.com/fearphage) in [#32237](https://github.com/backstage/backstage/pull/32237)
### Additional Kafka Events streaming settings
The Kafka event module now supports `fromBeginning` offsets and `autoCommit`.
Contributed by [@imod](https://github.com/imod) in [#31410](https://github.com/backstage/backstage/pull/31410)
### Improvements to the `home` plugin UI
Widget configuration changes are now only saved when the Save button is explicitly clicked. A new Cancel button has been added to enable users to discard unsaved changes
Contributed by [@kmikko](https://github.com/kmikko) in [#31198](https://github.com/pull/31198)
### Improved performance for `GithubOrgEntityProvider`
`GithubOrgEntityProvider` membership event handling and edit team has been improved. The provider now fetches only the specific user's teams instead of all organization users when processing membership events, and uses `addEntitiesOperation` instead of `replaceEntitiesOperation` to avoid unnecessary entity deletions.
Contributed by [@angeliski](https://github.com/angeliski) in [#32184](https://github.com/pull/32184)
### `Link` component now uses React Router’s navigation system
Previously the `Link` component would cause hard page refreshes for internal routes. With this update, the component now properly uses React Router’s navigation instead of full page reloads.
## Security Fixes
This release contains security fixes for Software Templates and reading external content.
## Upgrade path
We recommend that you keep your Backstage project up to date with this latest release. For more guidance on how to upgrade, check out the documentation for [keeping Backstage updated](https://backstage.io/docs/getting-started/keeping-backstage-updated).
## Links and References
Below you can find a list of links and references to help you learn about and start using this new release.
- [Backstage official website](https://backstage.io/), [documentation](https://backstage.io/docs/), and [getting started guide](https://backstage.io/docs/getting-started/)
- [GitHub repository](https://github.com/backstage/backstage)
- Backstage's [versioning and support policy](https://backstage.io/docs/overview/versioning-policy)
- [Community Discord](https://discord.gg/backstage-687207715902193673) for discussions and support
- [Changelog](https://github.com/backstage/backstage/tree/master/docs/releases/v1.47.0-changelog.md)
- Backstage [Demos](https://backstage.io/demos), [Blog](https://backstage.io/blog), [Roadmap](https://backstage.io/docs/overview/roadmap) and [Plugins](https://backstage.io/plugins)
Sign up for our [newsletter](https://info.backstage.spotify.com/newsletter_subscribe) if you want to be informed about what is happening in the world of Backstage.
docs/tooling/cli/02-build-system.md
+12 -9
View File
@@ -417,7 +417,7 @@ The following is an example of a `Dockerfile` that can be used to package the
output of building a package with role `'backend'` into an image:
```Dockerfile
FROM node:20-bookworm-slim
FROM node:24-trixie-slim
WORKDIR /app
COPY yarn.lock package.json packages/backend/dist/skeleton.tar.gz ./
@@ -610,7 +610,7 @@ With that in mind, here are some IDEs configurations to run backstage components
1. Click on "Edit Configurations" on top panel
2. In the modal dialog click on link "Edit configuration templates..." located in the bottom left corner.
3. "Configuration file": leave empty (`backstage-cli` adds the config)
4. "Node options": `--no-node-snapshot --experimental-vm-modules`
4. "Node options": ` --experimental-vm-modules`
5. "Jest package": `~/workspace/backstage/node_modules/@backstage/cli` - the location of the backstage cli package.
6. "Working directory": `~/workspace/backstage`
7. "Jest Options": `repo test --runInBand --watch=false`
@@ -621,20 +621,21 @@ With that in mind, here are some IDEs configurations to run backstage components
#### VS Code
1. Install the [Jest extension](https://marketplace.visualstudio.com/items?itemName=Orta.vscode-jest) for VS Code.
2. Update `settings.json` in the `.vscode` folder with:
```jsonc
{
"jest.jestCommandLine": "yarn test",
// In a large repo like the Backstage main repo you likely want to disable
// watch mode and the initial test run too, leaving just manual and perhaps
// on-save test runs in place.
"jest.autoRun": {
"watch": false,
"onSave": "test-src-file"
}
"jest.runMode": "on-save"
}
```
A complete launch configuration for VS Code debugging may look like this:
3. Add a launch configuration for VS Code in `launch.json` in the `.vscode` folder.
A complete configuration for debugging may look like this:
```jsonc
{
@@ -653,11 +654,13 @@ A complete launch configuration for VS Code debugging may look like this:
],
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen",
"disableOptimisticBPs": true,
"program": "${workspaceFolder}/node_modules/.bin/backstage-cli"
"program": "${workspaceFolder}/node_modules/@backstage/cli/bin/backstage-cli"
}
```
4. The configuration is not for manual runs from the "Run and Debug" view.
Instead use the Jest test explorer or the [test's gutter menu](https://github.com/jest-community/vscode-jest#how-to-trigger-a-test-run).
## Publishing
Package publishing is an optional part of the Backstage build system and not
docs/tooling/cli/03-commands.md
+73 -2
View File
@@ -432,8 +432,79 @@ Usage: backstage-cli create-github-app <github-org>
Outputs debug information which is useful when opening an issue. Outputs system
information, node.js and npm versions, CLI version and type (inside backstage
repo or a created app), all `@backstage/*` package dependency versions.
repo or a created app), all `@backstage/*` package dependency versions, and any
packages that contain a `backstage` field in their `package.json`.
The command distinguishes between installed packages (from npm) and local
workspace packages, making it easier to understand your Backstage setup.
```text
Usage: backstage-cli info
Usage: backstage-cli info [options]
Options:
--include <patterns...> Glob patterns for additional packages to include
(e.g., @mycompany/backstage-*)
--format <text|json> Output format (default: text)
-h, --help display help for command
```
### Examples
Output debug information to the console:
```bash
yarn backstage-cli info
```
Include additional packages matching a glob pattern:
```bash
yarn backstage-cli info --include "@mycompany/*"
```
Output as JSON:
```bash
yarn backstage-cli info --format json
```
Export JSON to a file for further processing:
```bash
yarn backstage-cli info --format json > backstage-info.json
```
Combine options to include custom packages and export to JSON:
```bash
yarn backstage-cli info --include "@mycompany/backstage-*" --include "@internal/*" --format json > debug-info.json
```
Export text output to a file:
```bash
yarn backstage-cli info --format text > backstage-info.txt
```
### JSON Output Format
When using `--format json`, the output is structured as follows:
```json
{
"system": {
"os": "Darwin 23.0.0 - darwin/arm64",
"node": "v18.17.0",
"yarn": "3.6.0",
"cli": { "version": "0.27.0", "local": false },
"backstage": "1.20.0"
},
"dependencies": {
"@backstage/core-plugin-api": "1.8.0",
"@backstage/plugin-catalog": "1.15.0"
},
"local": {
"@mycompany/backstage-plugin-custom": "0.1.0"
}
}
```
docs/tutorials/jest30-migration.md
+95
View File
@@ -0,0 +1,95 @@
---
id: jest30-migration
title: Migrating to Jest 30
description: A guide to migrating your project to Jest 30 and JSDOM 27
---
Starting with a recent version of `@backstage/cli`, `jest` is a peer dependency. If you run tests using Backstage CLI, you must add Jest and its environment dependencies as `devDependencies` in your project.
You can choose to install either Jest 29 or Jest 30. The built-in Jest version before this change was Jest 29, however, we recommend that you switch to Jest 30. Upgrading will solve the `Could not parse CSS stylesheet` errors, allow you to use MSW v2 in web packages, and ensure that you remain compatible with future versions of the Backstage CLI. Support for Jest 29 is temporary, with the purpose of allowing you to upgrade at your own pace, but it will eventually be removed.
- **Jest 29**:
```bash
# in your repository root, run:
yarn add --dev jest@^29 @types/jest@^29 jest-environment-jsdom@^29
```
Pros: No migration needed
Cons: You may see `Could not parse CSS stylesheet` warnings/errors when testing components from `@backstage/ui` or other packages using CSS `@layer` declarations
- **Jest 30**:
```bash
# in your repository root, run:
yarn add --dev jest@^30 @types/jest@^30 @jest/environment-jsdom-abstract@^30 jsdom@^27
```
Pros: Fixes the stylesheet parsing warnings/errors
Cons: Requires migration steps (see below) in your tests
## Migration Guide
The examples below are issues we encountered while migrating the Backstage repository. For a complete list of breaking changes, see the official documentation:
- [Jest 30 upgrade guide](https://jestjs.io/docs/upgrading-to-jest30)
- [JSDOM changelog](https://github.com/jsdom/jsdom/releases)
### Jest 30
**Asymmetric matchers with arrays**: `expect.objectContaining()` no longer works with arrays.
```diff
- expect(result).toEqual(expect.objectContaining([{ id: '123' }]));
+ expect(result).toEqual([{ id: '123' }]);
// or
+ expect(result).toEqual(expect.arrayContaining([{ id: '123' }]));
```
**Array length assertions**: `expect.objectContaining({ length: N })` no longer works.
```diff
- expect(fn).toHaveBeenCalledWith(expect.objectContaining({ length: 2 }));
+ expect(fn).toHaveBeenCalledWith(expect.any(Array));
+ expect(fn.mock.calls[0][0]).toHaveLength(2);
```
**Deprecated matcher aliases removed**: Replace with canonical names.
```diff
- expect(fn).toBeCalled();
+ expect(fn).toHaveBeenCalled();
```
**Snapshots**: Regenerate snapshots as the header format has changed.
```bash
yarn test --no-watch -u
```
### JSDOM 27
**window.location is non-configurable**: You can no longer mock location via `Object.defineProperty`.
```diff
- Object.defineProperty(window, 'location', { value: { href: '' } });
+ // Option 1: Use history API
+ history.replaceState({}, '', '/new-path');
+ // Option 2: Spy on navigation methods
+ const spy = jest.spyOn(component, 'navigate');
```
**CSS color values**: Colors may be returned as RGB instead of named colors.
```diff
- expect(element.style.color).toBe('red');
+ expect(element.style.color).toBe('rgb(255, 0, 0)');
```
**Error format changes**: Error messages and stack traces may have different formatting.
#### If you run into `Cannot read properties of null (reading 'constructor')`
Certain Backstage UI-components (e.g. Button) have a combination of CSS that triggers this error in tests. The solution is to make sure you have at least v0.9.25 of `@acemir/cssom`.
docs/tutorials/using-backstage-proxy-within-plugin.md
+8 -8
View File
@@ -94,15 +94,15 @@ export const AwesomeUsersTable = () => {
This section describes the steps to wrap your API client in a [Utility API](../api/utility-apis.md), which are:
- use [`createApiRef`](../reference/core-plugin-api.createapiref.md) to create a
new [`ApiRef`](../reference/core-plugin-api.apiref.md)
- register an [`ApiFactory`](../reference/core-plugin-api.apifactory.md) with
- use [`createApiRef`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiRef.html) to create a
new [`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)
- register an [`ApiFactory`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiFactory.html) with
your plugin using
[`createApiFactory`](../reference/core-plugin-api.createapifactory.md). This
[`createApiFactory`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiFactory.html). This
will wrap your API implementation, associate your `ApiRef` with your
implementation and tell backstage how to instantiate it
- finally, you can use your API in your components by calling
[`useApi`](../reference/core-plugin-api.useapi.md)
[`useApi`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.useApi.html)
### Defining the API client interface
@@ -187,8 +187,8 @@ export class MyAwesomeApiClient implements MyAwesomeApi {
```
> Check out the docs for more information on the
> [DiscoveryApi](../reference/core-plugin-api.discoveryapi.md) or the
> [FetchApi](../reference/core-plugin-api.fetchapi.md)
> [DiscoveryApi](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.DiscoveryApi.html) or the
> [FetchApi](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.FetchApi.html)
### Bundling your ApiRef with your plugin
@@ -233,7 +233,7 @@ export const myCustomPlugin = createPlugin({
### Using the API in your components
Now you should be able to access your API using the backstage hook
[`useApi`](../reference/core-plugin-api.useapi.md) from within your plugin code.
[`useApi`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.useApi.html) from within your plugin code.
```ts title="plugins/my-awesome-plugin/src/components/AwesomeUsersTable.tsx"
import { useApi } from '@backstage/core-plugin-api';