Releases: backstage/backstage
v1.39.0-next.2
See docs/releases/v1.39.0-next.2-changelog.md for more information.
v1.39.0-next.1
See docs/releases/v1.39.0-next.1-changelog.md for more information.
v1.39.0-next.0
See docs/releases/v1.39.0-next.0-changelog.md for more information.
v1.38.1
v1.38.0
These are the release notes for the v1.38.0 release of Backstage.
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: Removal of React imports
Backstage projects now ship with the new JSX transforms enabled by default, which removes the need for any default React imports. They are not yet included in the common configuration in the CLI, but you can enable them in your own project by adding the following under "compilerOptions" in your tsconfig.json: "jsx": "react-jsx".
To go along with this change the ESLint configuration in @backstage/cli has a new set of rules that produces warnings if React default imports are used. We recommend all adopters to switch to the new JSX transforms at their earliest convenience.
For more information, see the JSX transform migration guide.
Contributed by @schultzp2020 in #29499
BREAKING: Github Integration Changes
The @backstage/plugin-catalog-backend-module-github now will reject any configuration that contains slashes in branch names. Branches with slashes in Backstage are currently unsupported (#2815), and allowing this would cause issues after ingestion.
Contributed by @lukealbao in #29424
Another breaking change is that the @backstage/plugin-scaffolder-backend-module-github module also now will use the default branch of main instead of master when publishing new repositories.
It can be configured to any other value from the default by using the defaultBranch input.
- id: publish
name: Publish
action: publish:github
input:
allowedHosts: ['github.com']
description: This is ${{ parameters.name }}
repoUrl: ${{ parameters.repoUrl }}
+ defaultBranch: 'master'Contributed by @QuadmanSWE in #29488
BREAKING: Translation key changes for Scaffolder Plugin
Some translations have changed the key that they are nested under as they have been refactored into a better place with the upcoming additions of createTemplateGlobal and createTemplateFilter.
This means that the translation keys have changed for actionsPage.content.tableCell.*. They have moved to their own root key renderSchema.* instead.
Contributed by @mbenson in #29383
backstage-cli repo start
In order to align on yarn start being the only command needed for local development, we’ve introduced a new repo start command to the backstage-cli for use in the root package.json.
This will allow users to just run yarn start in the root of the repository. It will run the app and/or backend package in the repository by default, but you can also select packages to run by name or path, as well as run plugin dev entry points by plugin ID. For more information on the available options, see the docs for the repo start command.
The new script is installed as follows, replacing the existing yarn start script:
{
"scripts": {
"start": "backstage-cli repo start"
}
}In order to help users migrate in existing projects, it is recommended to replace existing scripts with the following in the root package.json:
{
"scripts": {
"dev": "echo \"Use 'yarn start' instead\"",
"start-backend": "echo \"Use 'yarn start backend' instead\""
}
}New plugin drop: 📦 Gateway Plugin
We have released @backstage/plugin-gateway-backend, a plugin for managing request routing in distributed Backstage deployments. This plugin is designed for organizations that have split their backend plugins across multiple Backstage deployments.
The gateway plugin addresses frontend-to-backend routing by providing a centralized routing solution in a dedicated "gateway" Backstage deployment. It routes frontend requests to the appropriate backend plugins using the Discovery service, while prioritizing local plugins when available.
Canon 0.3.0
Our new design system Canon has reached 0.3.0 in this release. You can read more about the changes in the canon changelog.
Movement towards Module Federation support
The new package @backstage/frontend-dynamic-features-loader provides a frontend feature loader that dynamically
loads frontend features based on the new frontend system and exposed as module federation remotes.
This new frontend feature loader works hand-in-hand with a new server of frontend plugin module federation
remotes, which is added as part of backend dynamic feature service in package @backstage/backend-dynamic-feature-service.
Contributed by @davidfestal in #28076
Catalog Events support for bitbucket-server
One of the oldest PRs that we had has finally been merged! We now have support for Bitbucket Server events, to automatically react to file changes to keep the catalog up to date.
Thanks for the effort from all involved to finally get this across the line 🎉
Contributed by @davelil4 in #19633
Redis clustering support
You can now enable Redis clustering, through the backend.cache.redis.cluster key.
Contributed by @marknach in #29162
Support for SRV look-ups in standard discovery
You can now use URLs on for example the form http+srv://recordname/api/{{pluginId}} in discovery.endpoints[].target.internal, to get automatic real-time SRV resolution of your internal deployments.
Send Slack notifications from the events system
There’s now a Slack processor for the notifications subsystem. Get notified right in your Slack workspace when things happen.
Contributed by @kunickiaj in #29308
New Frontend System Improvements
It is now possible to add custom header menu items to the entity page, see the example below:
import { EntityContextMenuItemBlueprint } from '@backstage/plugin-catalog-react/alpha';
const customEntityMenuItem = EntityContextMenuItemBlueprint.make({
name: 'custom-entity-menu-item',
params: {
icon: <ExampleIcon />,
useProps() {
// Other hooks can be called here
return {
title: 'Example title',
href: '/example-path', // or onClick: () => window.alert('Hello world!'),
disabled: false,
};
},
},
});Contributed by @marknotfound in #29515
Massive appreciation to the 55 amazing contributors who made this release possible by merging 188 pull requests: @acierto, @aladjadj, @alex-mckay, @AmbrishRamachandiran, @aramissennyeydd, @awanlin, @benjdlambert, @benjidotsh, @BethGriggs, @BingeCode, @camilaibs, @carlosmonastyrski, @cdedreuille, @davidfestal, @deepthi-28, @djamaile, @drodil, @Erob711, @fengypants, @freben, @its-mitesh-kumar, @jboeijenga, @JeevaRamanathan, @JohannesWill, @johnphilip283, @jpbottinelli, @knowacki23, @kunickiaj, @lavanya-sainik-ericsson, @lukealbao, @marians, @mario-mui, @marknotfound, @mbenson, @nasyrov-r, @Naycon, @nBerg, @Parsifal-M, @patroswastik, @PeaWarrior, @pmckl, @punkle, @QuadmanSWE, @rpasaporte, @Rugvip, @schultzp2020, @secustor, @squid-ney, @tklever, @tylerd-canva, @UsainBloot, @vinzscam, @vitasek01, @wrighbr, @YuvalFireFly.
Security Fixes
This release contains a security improvement that addresses potential information leakage of policies within the permission system.
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.
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, documentation, and getting started guide
- GitHub repository
- Backstage's versioning and support policy
- Community Discord for discussions and support
- Changelog
- Backstage Demos, Blog, Roadmap and Plugins
Sign up for our newsletter if you want to be informed about what is happening in the world of Backstage.
Contributors
Assets 2
v1.38.0-next.2
See docs/releases/v1.38.0-next.2-changelog.md for more information.
v1.37.1
This release fixes the following issues:
- Due to an accidental removal of a deprecated NestedValue helper in a minor library update, this change re-exports the type to prevent premature e2e tests breakage until the library is fully upgraded. For more details see: #29434
- There were two conflicting catalog service references that expected different implementation types, meaning they could not be used interchangeably. To fix this, we are now using a different ID for the deprecated alpha version of the catalog service ref. For more details see: #29450.
v1.38.0-next.1
See docs/releases/v1.38.0-next.1-changelog.md for more information.
v1.38.0-next.0
See docs/releases/v1.38.0-next.0-changelog.md for more information.
v1.37.0
These are the release notes for the v1.37.0 release of Backstage.
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: Removals of Old Backend System support
We are gradually removing support for the old backend system from plugins and modules. In this release, the most significant such changes are the app, events, proxy, search, techdocs, and user-settings plugins and their modules. It also affects parts of the permissions framework.
If you have already migrated to the new backend system, you will not be required to do any code changes, except perhaps removing the /alpha suffix on your imports if you had that.
If you have not yet migrated, now would be a great time to do so.
Note that for the @backstage/plugin-search-backend and @backstage/plugin-techdocs-backend packages, this necessitated a major semantic version bump. The others are on version 0.x still and received a minor level bump. If you are using the Backstage yarn plugin, you will get on the new versions automatically. If you do not, you may want to bump your dependency ranges (to e.g. ^2.0.0 for the major bumps) for these to ensure that you keep getting the most recent updates.
Along with the major bump, most of the previously already deprecated exports were finally removed as well from these packages. There are a bit too many to list here, but as an example, some of the old deprecated exports from the Techdocs backend have been available from their new home in @backstage/plugin-techdocs-node instead.
An upshot of these changes is that we have nearly entirely eliminated the usage of the old @backstage/backend-common package. We hope to get rid of the very final remnants of it as soon as possible.
BREAKING: Better Frontend Discovery
By default, your frontend will be using a more featureful discovery API implementation. The old one basically always pointed at your backend base URL. The new one lets you add a discovery.endpoints configuration section where you can easily point individual plugins to their own targets, simplifying the routing of split backend deployments without having to resort to implementing your own discovery. As the discovery.endpoints was already in use by the backend discovery service, this is marked as a breaking change, because it might cause any existing discovery.endpoints configuration to be picked up and used by the frontend discovery, which may break existing setups.
For example, consider the following configuration:
app:
baseUrl: https://backstage.acme.org
backend:
baseUrl: https://backstage.internal.acme.org
discovery:
endpoints:
- target: https://catalog.internal.acme.org/api/{{pluginId}}
plugins: [catalog]This will now cause requests from the frontend towards the catalog plugin to be routed to https://catalog.internal.acme.org/api/catalog, but this might not be reachable from the frontend. To fix this, you should update the discovery.endpoints configuration to only override the internal URL of the plugin:
discovery:
endpoints:
- target:
internal: https://catalog.internal.acme.org/api/{{pluginId}}
plugins: [catalog]
BREAKING: Linting Warnings
Our builtin CLI lint commands used to be unforgiving of warnings by default. This has now been relaxed, such that it instead behaves like eslint itself does: warnings are just warnings and do not trigger a failure. To restore the previous behavior, include the --max-warnings 0 flag in your backstage-cli <repo|package> lint commands.
Contributed by @schultzp2020 in #28699
BREAKING: Test Utilities
The @backstage/backend-test-utils database utilities now also cover Postgres major versions up to 17. If you were using the TestDatabases class without specifying what exact versions to test against, your tests will start covering Postgres 17 as well.
The deprecated setupRequestMockHandlers was also finally removed, please use registerMswTestHooks instead.
Native Zod Schemas for createTemplateAction
We’ve revisited how to create Template Actions using the new createTemplateAction method. The new way has first class support for zod schemas, so you no longer need to think about zodToJsonSchema, or manually creating the JSONSchema and the type parameters for typing the inputs and outputs for the actions.
The new API also drops support for ctx.logStream as this has been deprecated and will be removed in future versions.
Example usage:
createTemplateAction({
id: 'test',
schema: {
input: {
repoUrl: z => z.string(),
},
output: {
test: z => z.string(),
},
},
handler: async ctx => {
// you can just use ctx.logger.log('...'), or if
// you really need a log stream you can do this:
const logStream = new PassThrough();
logStream.on('data', chunk => {
ctx.logger.info(chunk.toString());
});
},
});There’s also some more information in the changeset.
New Frontend System improvements
There’s now a DialogApi, which greatly helps with placing dialogs in front of your users - in particular from code that lives outside the React tree, such as in callbacks.
At the same time, an EntityHeaderBlueprint lets you specifically replace the entity page headers. You can now also group multiple entity page contents into a single tab. A tab that groups more than one entity content is rendered as a dropdown menu. You can use the default list of tab groups or create your own. Groups are sorted in the same order as they are defined in the app-config.yaml file. The association between an entity content and a tab group can be optionally done when creating the content extension or via the app-config.yaml file. See usage examples in the #28701 and #29043 pull requests.
Another entity page feature introduced in this release is custom entity overview content layouts. It is now possible to have multiple overview content layouts. The layouts will be selected based on an entity filter defined when creating the layout extension or later via app-config-file. This change also allowed us to improve the default entity overview content layout. It now has 3 different types of areas that you can optionally assign to overview cards and have them rendered as a summary, information, or content card. Check out the following pull requests for more information: #28758,#28950, #28928 and #29145.
The concept of an extensionFactoryMiddleware was also added, which lets you add behaviors globally around any extension factory. This is useful for injecting debugging, analytics and much more. Contributed by @iamEAP in #29068.
Another exciting development is that the catalog gradually is adopting a new query format. For now it’s only used in the new frontend system for specifying the conditions under which e.g. a card should appear on the entity page. Eventually, it may be extended to the server side of the catalog as well to allow for more expressive queries. Check out the entity predicates documentation if you are curious!
A bit of a lower level (but technically breaking) change is that the return type of createSpecializedApp was changed to allow for better iteration on it in the future. You are unlikely to have been using this internal function, but if you did, more information is in the PR. The opaque old ExtensionOverrides and BackstagePlugin types were removed as well. This should not have an effect on end users, unless you are using a mixture of a new frontend framework and rather old plugins - if you see this causing any issues, please try updating the plugins as well.
Version Bump of TypeScript
In accordance with our versioning policy, new Backstage installations will now be based on TypeScript version 5.8, while our internal development moves up to version 5.6.
We recommend that you upgrade the TypeScript version in your own repositories to at least version 5.6 so that you are guaranteed to be up to date with the features used by libraries that we publish.
Delete “Provider Orphaned” Entities
It used to be that if you removed an entity provider, the entities it had put in the catalog remained and needed manual cleanup. There’s now a new catalog.orphanProviderStrategy configuration parameter that lets you opt in to having these be automatically deleted instead. Contributed by @UsainBloot in #28971
Huge thanks to all 52 of you incredible people who contributed to this release 🙌: @acierto, @alex-mckay, @alexlorenzi, @AmbrishRamachandiran, @angeliski, @apc-kamezaki, @aramissennyeydd, @awanlin, @b...
