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

Merge pull request #24718 from backstage/rugvip/multi-line

Browse Source 
docs: fix broken links + verify
This commit is contained in:
Patrik Oldsberg
2024-05-10 13:59:03 +02:00
committed by GitHub
parent 125eb7067c c3623c0cb6
commit 9f8307f6b6
39 changed files with 134 additions and 190 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/auth/cloudflare/access.md
+1 -2
View File
@@ -170,6 +170,5 @@ backend.add(customAuth);
The body of the sign-in resolver is up to you to write! The example code above
is just a copy of what `emailMatchingUserEntityProfileEmail` does. The `info`
parameter contains all of the results of the sign-in attempt so far. The `ctx`
context [has several useful
functions](https://backstage.io/docs/reference/plugin-auth-node.authresolvercontext/)
context [has several useful functions](https://backstage.io/docs/reference/plugin-auth-node.authresolvercontext/)
for issuing tokens in various ways.
docs/auth/identity-resolver.md
+5 -10
View File
@@ -5,8 +5,7 @@ description: An introduction to Backstage user identities and sign-in resolvers
---
:::info
This documentation is written for [the new backend
system](../backend-system/index.md) which is the default since Backstage
This documentation is written for [the new backend system](../backend-system/index.md) which is the default since Backstage
[version 1.24](../releases/v1.24.0.md). If you are still on the old backend
system, you may want to read [its own article](./identity-resolver--old.md)
instead, and [consider migrating](../backend-system/building-backends/08-migrating.md)!
@@ -31,15 +30,13 @@ testing purposes and quickly getting started locally, but is not safe for use in
production and that particular provider will refuse to work there.
Because of this, one of the early things you want to do when standing up your
Backstage instance is to choose a production ready auth provider. See [the auth
overview page](./index.md) for a full list of providers and how to install and
Backstage instance is to choose a production ready auth provider. See [the auth overview page](./index.md) for a full list of providers and how to install and
configure them.
## Backstage User Identity
A user identity within Backstage is built up from two main pieces of
information: a user [entity
reference](../features/software-catalog/references.md), and a set of ownership
information: a user [entity reference](../features/software-catalog/references.md), and a set of ownership
references. When a user signs in, a Backstage token is generated which is then
used to identify the user within the Backstage ecosystem.
@@ -194,8 +191,7 @@ backend.add(import('@backstage/plugin-auth-backend-module-github-provider'));
backend.add(customAuth);
```
Check out [the naming patterns
article](../backend-system/architecture/07-naming-patterns.md) for what rules
Check out [the naming patterns article](../backend-system/architecture/07-naming-patterns.md) for what rules
apply regarding how to form valid IDs. In this example we also put the module
declaration directly in `packages/backend/src/index.ts` but that's just for
simplicity. You can place it anywhere you like, including in other packages, and
@@ -244,8 +240,7 @@ async signInResolver(info, ctx) {
If you throw an error in the sign in resolver function, the sign in attempt is
immediately rejected, and the error details are presented in the user interface.
The `ctx` context [has several useful
functions](https://backstage.io/docs/reference/plugin-auth-node.authresolvercontext/)
The `ctx` context [has several useful functions](https://backstage.io/docs/reference/plugin-auth-node.authresolvercontext/)
for issuing tokens in various ways.
### Custom Ownership Resolution
docs/auth/microsoft/provider.md
+1 -2
View File
@@ -103,6 +103,5 @@ hosts:
- `login.microsoftonline.com`, to get and exchange authorization codes and access
tokens
- `graph.microsoft.com`, to fetch user profile information (as seen
in [this source
code](https://github.com/seanfisher/passport-microsoft/blob/0456aa9bce05579c18e77f51330176eb26373658/lib/strategy.js#L93-L95)).
in [this source code](https://github.com/seanfisher/passport-microsoft/blob/0456aa9bce05579c18e77f51330176eb26373658/lib/strategy.js#L93-L95)).
If this host is unreachable, users may see an `Authentication failed, failed to fetch user profile` error when they attempt to log in.
docs/auth/service-to-service-auth.md
+1 -2
View File
@@ -6,8 +6,7 @@ description: This section describes service to service authentication works, bot
---
:::info
This documentation is written for [the new backend
system](../backend-system/index.md) which is the default since Backstage
This documentation is written for [the new backend system](../backend-system/index.md) which is the default since Backstage
[version 1.24](../releases/v1.24.0.md). If you are still on the old backend
system, you may want to read [its own article](./service-to-service-auth--old.md)
instead, and [consider migrating](../backend-system/building-backends/08-migrating.md)!
docs/auth/vmware-cloud/provider.md
+4 -8
View File
@@ -12,14 +12,11 @@ Cloud Console and within a Backstage app required to enable this capability.
## Create an OAuth App in the VMware Cloud Console
1. Log in to the [VMware Cloud Console](https://console.cloud.vmware.com).
1. Navigate to [Identity & Access Management > OAuth
Apps](https://console.cloud.vmware.com/csp/gateway/portal/#/consumer/usermgmt/oauth-apps)
and click the [Owned
Apps](https://console.cloud.vmware.com/csp/gateway/portal/#/consumer/usermgmt/oauth-apps/owned-apps/view)
1. Navigate to [Identity & Access Management > OAuth Apps](https://console.cloud.vmware.com/csp/gateway/portal/#/consumer/usermgmt/oauth-apps)
and click the [Owned Apps](https://console.cloud.vmware.com/csp/gateway/portal/#/consumer/usermgmt/oauth-apps/owned-apps/view)
tab -- if you are not an Organization Owner or Administrator but only a
Member, you will not see this nav entry unless the **Developer** check box is
selected for your role (see the [Organization roles and
permissions](https://docs.vmware.com/en/VMware-Cloud-services/services/Using-VMware-Cloud-Services/GUID-C11D3AAC-267C-4F16-A0E3-3EDF286EBE53.html#organization-roles-and-permissions-0)
selected for your role (see the [Organization roles and permissions](https://docs.vmware.com/en/VMware-Cloud-services/services/Using-VMware-Cloud-Services/GUID-C11D3AAC-267C-4F16-A0E3-3EDF286EBE53.html#organization-roles-and-permissions-0)
docs for details).
1. Click **Create App**, choose 'Web/Mobile app' and click **Continue**.
1. Use default settings except:
@@ -161,8 +158,7 @@ auth:
```
Where `APP_ID` refers to the ID retrieved when creating the OAuth App, and
`ORG_ID` is the [long ID of the
Organization](https://docs.vmware.com/en/VMware-Cloud-services/services/Using-VMware-Cloud-Services/GUID-CF9E9318-B811-48CF-8499-9419997DC1F8.html#view-the-organization-id-1)
`ORG_ID` is the [long ID of the Organization](https://docs.vmware.com/en/VMware-Cloud-services/services/Using-VMware-Cloud-Services/GUID-CF9E9318-B811-48CF-8499-9419997DC1F8.html#view-the-organization-id-1)
in VMware Cloud for which you wish to enable sign-in.
Note that VMware Cloud requires OAuth Apps to use
docs/backend-system/building-plugins-and-modules/01-index.md
+4 -9
View File
@@ -73,8 +73,7 @@ items.
Backend modules are used to extend [plugins](../architecture/04-plugins.md) or other modules with
additional features or change existing behavior. They must always be installed
in the same backend instance as the plugin or module that they extend, and may only extend a single plugin and modules from that plugin at a time.
Modules interact with their target plugin or module using the [extension
points](../architecture/05-extension-points.md) registered by the plugin, while also being
Modules interact with their target plugin or module using the [extension points](../architecture/05-extension-points.md) registered by the plugin, while also being
able to depend on the [services](../architecture/03-services.md) of the target plugin.
That last point is worth reiterating: injected `plugin` scoped services will be
the exact
@@ -157,8 +156,7 @@ the database. They will run on the same logical database instance as the target
plugin, so care must be taken to choose table names that do not risk colliding
with those of the plugin. A recommended naming pattern is `<package
name>__<table name>`, for example the `@backstage/backend-tasks` package creates
tables named `backstage_backend_tasks__<table>`. If you use the default [`Knex`
migration facilities](https://knexjs.org/guide/migrations.html), you will also
tables named `backstage_backend_tasks__<table>`. If you use the default [`Knex` migration facilities](https://knexjs.org/guide/migrations.html), you will also
want to make sure that it uses similarly prefixed migration state tables for its
internal bookkeeping needs, so they do not collide with the main ones used by
the plugin itself. You can do this as follows:
@@ -179,8 +177,7 @@ There are several ways of configuring and customizing plugins and modules.
Whenever you want to allow modules to configure your plugin dynamically, for
example in the way that the catalog backend lets catalog modules inject
additional entity providers, you can use the extension points mechanism. This is
described in detail with code examples in [the extension points architecture
article](../architecture/05-extension-points.md), while the following is a more
described in detail with code examples in [the extension points architecture article](../architecture/05-extension-points.md), while the following is a more
slim example of how to implement an extension point for a plugin:
```ts
@@ -249,7 +246,5 @@ export const examplePlugin = createBackendPlugin({
});
```
Before adding custom configuration options, make sure to read [the configuration
docs](../../conf/index.md), in particular the section on [defining configuration
for your own plugins](../../conf/defining.md) which explains how to establish a
Before adding custom configuration options, make sure to read [the configuration docs](../../conf/index.md), in particular the section on [defining configuration for your own plugins](../../conf/defining.md) which explains how to establish a
configuration schema for your specific plugin.
docs/backend-system/building-plugins-and-modules/02-testing.md
+1 -2
View File
@@ -21,8 +21,7 @@ collective term for backend [plugins](../architecture/04-plugins.md) and
The function returns an HTTP server instance which can be used together with
e.g. `supertest` to easily test the actual REST service surfaces of plugins who
register routes with [the HTTP router service
API](../core-services/01-index.md).
register routes with [the HTTP router service API](../core-services/01-index.md).
```ts
import { mockServices, startTestBackend } from '@backstage/backend-test-utils';
docs/features/kubernetes/configuration.md
+3 -6
View File
@@ -198,8 +198,7 @@ in namespace `NAMESPACE` and it has adequate
[permissions](#role-based-access-control), here are some sample procedures to
procure a long-lived service account token for use with this provider:
- On versions of Kubernetes [prior to
1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#no-really-you-must-read-this-before-you-upgrade-1),
- On versions of Kubernetes [prior to 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#no-really-you-must-read-this-before-you-upgrade-1),
you could get an (automatically-generated) token for a service account with:
```sh
@@ -209,8 +208,7 @@ procure a long-lived service account token for use with this provider:
| base64 --decode
```
- For Kubernetes 1.24+, as described in [this
guide](https://kubernetes.io/docs/concepts/configuration/secret/#service-account-token-secrets),
- For Kubernetes 1.24+, as described in [this guide](https://kubernetes.io/docs/concepts/configuration/secret/#service-account-token-secrets),
you can obtain a long-lived token by creating a secret:
```sh
@@ -235,8 +233,7 @@ procure a long-lived service account token for use with this provider:
If a cluster has `authProvider: serviceAccount` and the `serviceAccountToken`
field is omitted, Backstage will ignore the configured URL and certificate data,
instead attempting to access the Kubernetes API via an in-cluster client as in
[this
example](https://github.com/kubernetes-client/javascript/blob/master/examples/in-cluster.js).
[this example](https://github.com/kubernetes-client/javascript/blob/master/examples/in-cluster.js).
##### `clusters.\*.oidcTokenProvider` (optional)
docs/features/kubernetes/proxy.md
+6 -12
View File
@@ -7,12 +7,10 @@ description: Interacting with the Kubernetes API in Backstage plugins
[Contributors](https://backstage.io/docs/overview/glossary#backstage-user-profiles) wanting to
create developer portal experiences based on data from Kubernetes (e.g. for
interacting with [Custom
Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
interacting with [Custom Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
beyond the default behaviors of the existing Kubernetes plugin) can leverage the
Kubernetes backend plugin's proxy endpoint to allow them to make arbitrary
requests to the [REST
API](https://kubernetes.io/docs/reference/using-api/api-concepts/).
requests to the [REST API](https://kubernetes.io/docs/reference/using-api/api-concepts/).
Here is a snippet fetching namespaces using the `KubernetesBackendClient` library
@@ -31,8 +29,7 @@ await kubernetesApi.proxy(CLUSTER_NAME, '/api/v1/namespaces');
The proxy will interpret the
[`Backstage-Kubernetes-Cluster`](https://backstage.io/docs/reference/plugin-kubernetes-backend.header_kubernetes_cluster)
header as the name of the cluster to target. This name will be compared to each cluster
returned by all the configured [cluster
locators](https://backstage.io/docs/features/kubernetes/configuration#clusterlocatormethods)
returned by all the configured [cluster locators](https://backstage.io/docs/features/kubernetes/configuration#clusterlocatormethods)
-- the first cluster whose [`name` field](https://backstage.io/docs/features/kubernetes/configuration#clustersname) matches
the value in the header will be targeted.
@@ -48,12 +45,10 @@ The proxy expects a `KubernetesAuthTranslator` to be provided that is used to de
## Authentication
The proxy has no provisions for mTLS, so it cannot be used to connect to
clusters using the [x509 Client
Certs](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs)
clusters using the [x509 Client Certs](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs)
authentication strategy.\
The current `/proxy` Implementation expects a
[Bearer
token](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#putting-a-bearer-token-in-a-request)
[Bearer token](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#putting-a-bearer-token-in-a-request)
to be provided as a `Backstage-Kubernetes-Authorization` header for a target cluster. This token will be used as the `Authorization` header when forwarding a request to a target cluster.
## How to disable the proxy endpoint via PermissionPolicy
@@ -104,8 +99,7 @@ even if a valid ID token was attached that a cluster would authorize.
## Other known limitations
The proxy as it was released in [Backstage
1.9](https://github.com/backstage/backstage/blob/master/docs/releases/v1.9.0-changelog.md#patch-changes-15)
The proxy as it was released in [Backstage 1.9](../../releases/v1.9.0-changelog.md#patch-changes-15)
has a known bug:
- [#15901](https://github.com/backstage/backstage/issues/15901) - it cannot
docs/features/software-catalog/index.md
+1 -2
View File
@@ -40,8 +40,7 @@ browse the catalog at `http://localhost:3000`.
## Adding components to the catalog
The source of truth for the components in your software catalog are [metadata
YAML files](descriptor-format.md) stored in source control (GitHub, GitHub
The source of truth for the components in your software catalog are [metadata YAML files](descriptor-format.md) stored in source control (GitHub, GitHub
Enterprise, GitLab, ...). Repositories can include one or multiple metadata
files. Usually the metadata file is located in the repository root. This is not
a formal requirement & metadata files can be placed anywhere in the repository.
docs/integrations/github/org--old.md
+1 -2
View File
@@ -308,8 +308,7 @@ const githubOrgProvider = GithubOrgEntityProvider.fromConfig(env.config, {
});
```
Once you have imported the emails you can resolve users in your [sign-in
resolver](../../auth/github/provider.md) using the catalog entity search via email
Once you have imported the emails you can resolve users in your [sign-in resolver](../../auth/github/provider.md) using the catalog entity search via email
```typescript title="packages/backend/src/plugins/auth.ts"
ctx.signInWithCatalogUser({
docs/overview/roadmap.md
+2 -4
View File
@@ -10,8 +10,7 @@ Backstage is currently under rapid development. This page details the project's
public roadmap, the result of ongoing collaboration between the core maintainers
and the broader Backstage community.
The Backstage roadmap lays out both [“what's next”](#whats-next) and ["future
work"](#future-work). With "next" we mean features planned for release within
The Backstage roadmap lays out both [“what's next”](#whats-next) and ["future work"](#future-work). With "next" we mean features planned for release within
the ongoing quarter from July through September 2022. With "future" we mean
features on the radar, but not yet scheduled.
@@ -52,8 +51,7 @@ the platform. The benefit for the adopters is clear: we want Backstage to be as
secure as possible, and we want to make it reliable through a specific
initiative.
This initiative is done together with, and with the support of, the [Cloud
Native Computing Foundation (CNCF)](https://www.cncf.io/).
This initiative is done together with, and with the support of, the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/).
### Backstage Threat Model
docs/plugins/analytics.md
+1 -2
View File
@@ -69,8 +69,7 @@ installed, may be captured.
| `discover` | The title of the search result that was clicked on | The `value` is the result rank. A `to` attribute is also provided. |
| `not-found` | The path of the resource that resulted in a not found page | Fired by at least TechDocs. |
If there is an event you'd like to see captured, please [open an
issue](https://github.com/backstage/backstage/issues/new?assignees=&labels=enhancement&template=feature_template.md&title=[Analytics%20Event]:%20THE+EVENT+TO+CAPTURE) describing the event you want to see and the questions it
If there is an event you'd like to see captured, please [open an issue](https://github.com/backstage/backstage/issues/new?assignees=&labels=enhancement&template=feature_template.md&title=[Analytics%20Event]:%20THE+EVENT+TO+CAPTURE) describing the event you want to see and the questions it
would help you answer. Or jump to [Capturing Events](#capturing-events) to learn how
to contribute the instrumentation yourself!
docs/releases/v1.12.0-changelog.md
+1 -2
View File
@@ -60,8 +60,7 @@
This change makes the dependence explicit, and removes the burden on
OAuth2-based providers which require an ID token (e.g. this is done by various
default [auth
handlers](https://backstage.io/docs/auth/identity-resolver/#authhandler)) to add
default [auth handlers](https://backstage.io/docs/auth/identity-resolver/#authhandler)) to add
`openid` to their default scopes. _That_ could carry another indirect benefit:
by removing `openid` from the default scopes for a provider, grants for
resource-specific access tokens can avoid requesting excess ID token-related
docs/releases/v1.12.0-next.2-changelog.md
+1 -2
View File
@@ -25,8 +25,7 @@
This change makes the dependence explicit, and removes the burden on
OAuth2-based providers which require an ID token (e.g. this is done by various
default [auth
handlers](https://backstage.io/docs/auth/identity-resolver/#authhandler)) to add
default [auth handlers](https://backstage.io/docs/auth/identity-resolver/#authhandler)) to add
`openid` to their default scopes. _That_ could carry another indirect benefit:
by removing `openid` from the default scopes for a provider, grants for
resource-specific access tokens can avoid requesting excess ID token-related
docs/releases/v1.15.0.md
+5 -10
View File
@@ -27,8 +27,7 @@ native dependency, and as such needs to be built during `yarn` installation, on
the exact architecture that it then executes on. For those who compile and run
Backstage on stripped-down environments, you will want to ensure that you have
the build basics present, e.g. `build-essential` or similar corresponding to
your operating system of choice. The `isolated-vm` repo has [some further
information](https://github.com/laverdet/isolated-vm#requirements) about the
your operating system of choice. The `isolated-vm` repo has [some further information](https://github.com/laverdet/isolated-vm#requirements) about the
build environment requirements.
There is a [CVE-2022-39266](https://www.cve.org/CVERecord?id=CVE-2022-39266)
@@ -65,8 +64,7 @@ covers of your catalog instance, finding those pesky unprocessed entities that
may be stuck in limbo because of an otherwise tricky-to-debug validation issue
or similar.
Check out [the plugin’s
README](https://github.com/backstage/backstage/blob/master/plugins/catalog-unprocessed-entities/README.md)
Check out [the plugin’s README](https://github.com/backstage/backstage/blob/master/plugins/catalog-unprocessed-entities/README.md)
for details and installation instructions.
Contributed by [@alde](https://github.com/alde) in
@@ -176,8 +174,7 @@ Contributed by [@sblausten](https://github.com/sblausten) in
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).
[keeping Backstage updated](https://backstage.io/docs/getting-started/keeping-backstage-updated).
## Links and References
@@ -185,11 +182,9 @@ 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/)
[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)
- 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.15.0-changelog.md)
docs/releases/v1.3.0-changelog.md
+1 -2
View File
@@ -883,8 +883,7 @@
### Patch Changes
- 8f7b1835df: Updated dependency `msw` to `^0.41.0`.
- 811ff4bcf4: Updated `swagger-ui-react` to 4.11.1 in order to address a [XSS
vulnerability](https://github.com/advisories/GHSA-hqq7-2q2v-82xq) in `@braintree/sanitize-url`
- 811ff4bcf4: Updated `swagger-ui-react` to 4.11.1 in order to address a [XSS vulnerability](https://github.com/advisories/GHSA-hqq7-2q2v-82xq) in `@braintree/sanitize-url`
- Updated dependencies
- @backstage/plugin-catalog@1.3.0
- @backstage/plugin-catalog-react@1.1.1
docs/releases/v1.6.0-changelog.md
+1 -3
View File
@@ -24,9 +24,7 @@
- 1fe6823bb5: Updated dependency `eslint-plugin-jest` to `^27.0.0`.
Note that this major update to the Jest plugin contains some breaking changes.
This means that some of your tests may start seeing some new lint errors. [Read
about them
here](https://github.com/jest-community/eslint-plugin-jest/blob/main/CHANGELOG.md#2700-2022-08-28).
This means that some of your tests may start seeing some new lint errors. [Read about them here](https://github.com/jest-community/eslint-plugin-jest/blob/main/CHANGELOG.md#2700-2022-08-28).
These are mostly possible to fix automatically. You can try to run `yarn backstage-cli repo lint --fix` in your repo root to have most or all of them
corrected.
docs/releases/v1.6.0-next.1-changelog.md
+1 -3
View File
@@ -7,9 +7,7 @@
- 1fe6823bb5: Updated dependency `eslint-plugin-jest` to `^27.0.0`.
Note that this major update to the Jest plugin contains some breaking changes.
This means that some of your tests may start seeing some new lint errors. [Read
about them
here](https://github.com/jest-community/eslint-plugin-jest/blob/main/CHANGELOG.md#2700-2022-08-28).
This means that some of your tests may start seeing some new lint errors. [Read about them here](https://github.com/jest-community/eslint-plugin-jest/blob/main/CHANGELOG.md#2700-2022-08-28).
These are mostly possible to fix automatically. You can try to run `yarn backstage-cli repo lint --fix` in your repo root to have most or all of them
corrected.
docs/releases/v1.7.0-changelog.md
+1 -2
View File
@@ -926,8 +926,7 @@
Migrating to the stable version of `react-router` is optional for the time
being. But if you want to do the same for your existing repository, please
follow [this
guide](https://backstage.io/docs/tutorials/react-router-stable-migration).
follow [this guide](https://backstage.io/docs/tutorials/react-router-stable-migration).
- e05e0f021b: Update versions of packages used in the create-app template, to match those in the main repo
docs/releases/v1.7.0-next.0-changelog.md
+1 -2
View File
@@ -319,8 +319,7 @@
Migrating to the stable version of `react-router` is optional for the time
being. But if you want to do the same for your existing repository, please
follow [this
guide](https://backstage.io/docs/tutorials/react-router-stable-migration).
follow [this guide](https://backstage.io/docs/tutorials/react-router-stable-migration).
- e05e0f021b: Update versions of packages used in the create-app template, to match those in the main repo
docs/releases/v1.7.0.md
+7 -15
View File
@@ -22,24 +22,20 @@ backend needs to be supplied with a location analyzer for this use case to
continue to function.
If you want to make use of this feature, check out the installation instructions
in [the
changelog](https://github.com/backstage/backstage/blob/master/plugins/catalog-import/CHANGELOG.md#090).
in [the changelog](https://github.com/backstage/backstage/blob/master/plugins/catalog-import/CHANGELOG.md#090).
Contributed by [@kissmikijr](https://github.com/kissmikijr) in
[#13800](https://github.com/backstage/backstage/pull/13800)
### Permission Rule Changes
When defining permission rules, it's now necessary to provide a [Zod
Schema](https://github.com/colinhacks/zod) that specifies the parameters the
When defining permission rules, it's now necessary to provide a [Zod Schema](https://github.com/colinhacks/zod) that specifies the parameters the
rule expects. This has been added to help better describe the parameters in the
response of the metadata endpoint and to validate the parameters before a rule
is executed. The signatures of the rule methods (`apply` and `toQuery`) have
changed slightly as well.
You can read more about this in [the permissions
documentation](https://backstage.io/docs/permissions/overview) and [the
changelog](https://github.com/backstage/backstage/blob/master/plugins/permission-node/CHANGELOG.md#070).
You can read more about this in [the permissions documentation](https://backstage.io/docs/permissions/overview) and [the changelog](https://github.com/backstage/backstage/blob/master/plugins/permission-node/CHANGELOG.md#070).
### Migration: `jest` v29
@@ -64,8 +60,7 @@ Newly created Backstage repositories now use the stable version 6 of
Migrating to the stable version of `react-router` is optional for the time
being; Backstage has support for both versions. But if you want to do the same
for your existing repository, please follow [this
guide](https://backstage.io/docs/tutorials/react-router-stable-migration).
for your existing repository, please follow [this guide](https://backstage.io/docs/tutorials/react-router-stable-migration).
Support for the beta version will be removed in a later release.
### Support for `__mocks__` and `__testUtils__` directories
@@ -100,8 +95,7 @@ This release does not contain any security fixes.
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).
[keeping Backstage updated](https://backstage.io/docs/getting-started/keeping-backstage-updated).
## Links and References
@@ -109,11 +103,9 @@ 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/)
[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)
- 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.7.0-changelog.md)
- Backstage [Demos](https://backstage.io/demos),