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

Merge branch 'backstage:master' into milliehartnt123-create-ui-doc

Browse Source
This commit is contained in:
milliehartnt123
2025-11-21 08:14:29 -05:00
committed by GitHub
parent 73ccc9bf38 c16d83c70c
commit aa51d79e89
784 changed files with 12259 additions and 4135 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/frontend-system/building-apps/08-migrating.md
+3 -48
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.
@@ -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`.
docs/frontend-system/building-plugins/05-migrating.md
+7 -14
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,18 +106,15 @@ 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';
import { compatWrapper } 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 =>
docs/integrations/bitbucketCloud/locations.md
+15 -3
View File
@@ -14,11 +14,22 @@ 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
```
:::note Note
@@ -30,7 +41,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/) or an [App Password](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/). An Atlassian Account API key will not work.
:::
@@ -42,4 +53,5 @@ 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.
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.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.