[release-v1.15][npm]: Bump @backstage/plugin-catalog from 1.15.1 to 1.31.3 in /backstage

[dependabot]

Bumps @backstage/plugin-catalog from 1.15.1 to 1.31.3.

Release notes

Sourced from @​backstage/plugin-catalog's releases.

v1.31.3

This release fixes an unexpected behaviour where configuration supplied with APP_CONFIG_* environment variables where not filtered by the configuration schema. If you are using APP_CONFIG_* to supply frontend configuration, you now need to make sure to define those configuration values in your configuration schema and set @visibility frontend.

This is treated as a security fix since the old behavior was dangerously unexpected.

v1.31.2

This release fixes an issue where the catalog would not refresh the TTL of the ProcessorCache when getting a NotModifiedError. Also reverts the removal of the api scope in GitLab SCM Auth, as it's required for a lot of existing use cases.

v1.31.1

This release fixes an issue where the .yarnrc.yml file was not included in projects created with @backstage/create-app.

v1.31.0

These are the release notes for the v1.31.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

Backend System 1.0 🎉

The time has come for releasing the new Backend System as stable version 1.0! This means that the API is now stable and breaking changes should not occur until version 2.0, see our package versioning policy for more information about this.

There is documentation in place both for migrating backends and migrating plugins, and we encourage you to start doing so as soon as possible. Going forward, we will increasingly refer to this as "The backend system", and the previous one as "The old backend system". The main Backstage and community-plugins repositories have already been more or less fully migrated over.

The backend system brings a host of improvements to the way that backends and their features are constructed. Instead of the old convention-based structure that could lead to migration pains, features now fit together with dependency injection like a jigsaw puzzle while leveraging powerful core services and extending each other dynamically with additional behaviors. And this is just scratching the surface of it - do check out the docs!

We are very excited about this important milestone after a long period of development and refinement together with our passionate community, and hope that you will find it as refreshing and simple yet powerful as it was envisioned to be. This also lays the foundation for us being able to continue iterating at a high pace without incurring undue end user breakages during upgrades.

Keep the feedback coming! Either on the Community Discord, or through issues on GitHub. Also if you’re looking for a way to help, please take a look at these backstage and community plugins issues about deprecating old-backend capabilities of already migrated plugins.

Technical details

At a technical level, the following packages are now on major version 1, and their major version 0 will stop receiving feature updates:

• @backstage/backend-app-api
• @backstage/backend-plugin-api
• @backstage/backend-test-utils

The following packages are deprecated and frozen (have stopped receiving updates). Please use the above three packages and @backstage/backend-defaults to replace them. You may still use the compatibility adapters in @backstage/backend-common short term while performing a gradual migration.

• @backstage/backend-common
• @backstage/backend-tasks

The following core services have been entirely removed. Please migrate to the new auth system.

• coreServices.identity
• coreServices.tokenManager

The backwards compatibility with plugins using legacy auth through the token manager service has also been removed. This means that instead of falling back to using the old token manager, requests towards plugins that don't support the new auth system will simply fail. Please make sure that all plugins in your deployment are hosted within a backend instance from the new backend system; a mixture of new and old will lead to auth problems.

... (truncated)

Changelog

Sourced from @​backstage/plugin-catalog's changelog.

1.31.3

Patch Changes

• 4316c11: Catalog table columns support i18n
• ce1239e: Auto-focus the first menu item in EntityContextMenu, and do not render a divider if an empty array is passed to UNSTABLE_extraContextMenuItems.
• 85c5e04: Fix incorrect defaultTarget on createComponentRouteRef.
• Updated dependencies
  • @​backstage/plugin-catalog-react@​1.21.0
  • @​backstage/plugin-techdocs-react@​1.3.3
  • @​backstage/frontend-plugin-api@​0.12.0
  • @​backstage/core-plugin-api@​1.11.0
  • @​backstage/catalog-client@​1.12.0
  • @​backstage/core-components@​0.18.0
  • @​backstage/types@​1.2.2
  • @​backstage/core-compat-api@​0.5.2
  • @​backstage/plugin-search-react@​1.9.4
  • @​backstage/integration-react@​1.2.10
  • @​backstage/plugin-scaffolder-common@​1.7.1

1.31.3-next.2

Patch Changes

• 85c5e04: Fix incorrect defaultTarget on createComponentRouteRef.
• Updated dependencies
  • @​backstage/catalog-client@​1.12.0-next.0
  • @​backstage/plugin-catalog-react@​1.21.0-next.2
  • @​backstage/core-components@​0.17.6-next.1
  • @​backstage/core-compat-api@​0.5.2-next.2

1.31.3-next.1

Patch Changes

• Updated dependencies
  • @​backstage/plugin-catalog-react@​1.20.2-next.1
  • @​backstage/frontend-plugin-api@​0.11.1-next.0
  • @​backstage/core-components@​0.17.6-next.0
  • @​backstage/core-compat-api@​0.5.2-next.1
  • @​backstage/plugin-search-react@​1.9.4-next.0
  • @​backstage/plugin-techdocs-react@​1.3.3-next.0
  • @​backstage/integration-react@​1.2.10-next.0
  • @​backstage/plugin-scaffolder-common@​1.7.1-next.0

1.31.3-next.0

Patch Changes

• ce1239e: Auto-focus the first menu item in EntityContextMenu, and do not render a divider if an empty array is passed to UNSTABLE_extraContextMenuItems.

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dependabot[bot]
Once this PR has been reviewed and has the lgtm label, please assign lberk for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @dependabot[bot]. Thanks for your PR.

I'm waiting for a openshift-knative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.