Bump @backstage/plugin-catalog from 1.26.0 to 1.28.0 in /backstage

[dependabot]

Bumps @backstage/plugin-catalog from 1.26.0 to 1.28.0.

Release notes

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

v1.28.0

These are the release notes for the v1.28.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: Proxy backend plugin protected by default

The proxy backend plugin is now protected by Backstage auth, by default. Unless specifically configured (see below), all proxy endpoints will reject requests immediately unless a valid Backstage user or service token is passed along with the request. This aligns the proxy with how other Backstage backends behave out of the box, and serves to protect your upstreams from unauthorized access.

Here's an example of how to configure:

  proxy:
    endpoints:
      '/pagerduty':
        target: https://api.pagerduty.com
+       credentials: require
        headers:
          Authorization: Token token=${PAGERDUTY_TOKEN}

There are three credentials settings:

• require: Callers need Backstage credentials. These are not forwarded to the target.
• forward: Callers need Backstage credentials, which are forwarded to the target.
• dangerously-allow-unauthenticated: No Backstage credentials needed. Target can apply its own checks. Incoming tokens of any sort will be allowed but ignored, and will also be forwarded if allowedHeaders: ['Authorization'] is included.

The new default is require, replacing the old dangerously-allow-unauthenticated. This means some previously permitted requests may now result in 401 Unauthorized responses. This does not apply if backend.auth.dangerouslyDisableDefaultAuthPolicy is set to true.

For proxy endpoints still requiring unauthenticated access, add credentials: dangerously-allow-unauthenticated in your app-config.

See the proxy documentation for more information.

BREAKING: Gerrit integration breaking changes

• The workdir argument have been removed from The GerritUrlReader constructor;
• The Gerrit readTree implementation will now only use the Gitiles api, so the support for using git to clone the repo has been removed;
• The gitilesBaseUrl is now mandatory for the Gerrit integration and the ability to override this requirement using the DISABLE_GERRIT_GITILES_REQUIREMENT environment variable has been removed.

Contributed by @​anicke in #25123.

BREAKING: Github integration breaking changes

• Removed deprecated code from when casing was changed from GitHub to Github nearly two years ago. The following items have been removed:
  • getGitHubFileFetchUrl (use getGithubFileFetchUrl instead)
  • GitHubIntegrationConfig (use GithubIntegrationConfig instead)
  • GitHubIntegration (use GithubIntegration instead)
  • readGitHubIntegrationConfig (use readGithubIntegrationConfig instead)

... (truncated)

Changelog

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

1.28.0

Minor Changes

• 247a40b: Now a custom entity page header can be passed as input to the default entity page.

• a3d93ca: The default layout of the entity page can now optionally be customized with 3 card types: info, peek and full.

  • Cards of type info are rendered in a fixed area on the right;
  • Cards of type peek are rendered on top of the main content area;
  • Cards of type full and cards with undefined type are rendered as they were before, in the main content area, below the peek cards.

  If you want to keep the layout as it was before, you don't need to do anything. But if you want to experiment with the card types and see how they render, here is an example setting the about card to be rendered as an info card:

  app:
    extensions:
      # Entity page cards
  +   - entity-card:catalog/about:
  +       config:
  +         type: info # or peek or full

• 93533bd: The order in which group tabs appear on the entity page has been changed.

  Before

  Previously, entity contents determined the order in which groups were rendered, so a group was rendered as soon as its first entity content was detected.

  After

  Groups are now rendered first by default based on their order in the app-config.yaml file:

  app:
    extensions:
      - page:catalog/entity:
  +       config:
  +         groups:
  +           # this will be the first tab of the default entity page
  +           - deployment:
  +               title: Deployment
  +           # this will be the second tab of the default entiy page
  +           - documentation:
  +               title: Documentation

  If you wish to place a normal tab before a group, you must add the tab to a group and place the group in the order you wish it to appear on the entity page (groups that contains only one tab are rendered as normal tabs).

  app:

... (truncated)

Commits

• 18a4042 Version Packages
• e83ead9 Version Packages (next)
• d44a20a add plugin metadata to all plugin packages
• 96091d3 fix missing actions after adding pagination to catalog table #25097
• 09f5022 Version Packages (next)
• 863a800 catalog: add default route targets
• 77da22e Version Packages (next)
• 9fde497 Merge pull request #24837 from brunobastosg/fix-catalog-translation
• 5b95868 Merge pull request #24518 from Zaperex/add-additional-scaffolder-permissions
• cce0495 Version Packages (next)
• Additional commits viewable 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)

[dependabot]

Superseded by #28.