Merge branch 'master' of github.com:backstage/backstage into GD-294-users-groups-ingestion
This commit is contained in:
Stephen Barry
+18
-18
@@ -15,35 +15,35 @@ There are multiple ways to contribute to making Backstage more accessible, you'l
|
||||
If your plugin lives in the [Backstage main repository](https://github.com/backstage/backstage/) you can modify the [urls in the Lighthouse config](https://github.com/backstage/backstage/blob/39ba2284d73885b7ca8290cb38e2b1e4d983c8d6/lighthouserc.js#L19-L34) to run the Lighthouse checks on urls where your plugin exists as well. E.g.
|
||||
|
||||
```diff
|
||||
ci: {
|
||||
collect: {
|
||||
url: [
|
||||
ci: {
|
||||
collect: {
|
||||
url: [
|
||||
/** Software Catalog */
|
||||
'http://localhost:3000/catalog',
|
||||
'http://localhost:3000/catalog-import',
|
||||
'http://localhost:3000/catalog/default/component/backstage',
|
||||
...
|
||||
+ /** Your plugin paths */
|
||||
+ 'http://localhost:3000/your-plugin-path,
|
||||
/** Software Catalog */
|
||||
'http://localhost:3000/catalog',
|
||||
'http://localhost:3000/catalog-import',
|
||||
'http://localhost:3000/catalog/default/component/backstage',
|
||||
],
|
||||
settings: {
|
||||
...
|
||||
],
|
||||
settings: {
|
||||
...
|
||||
},
|
||||
...
|
||||
},
|
||||
assert: {
|
||||
},
|
||||
...
|
||||
},
|
||||
},
|
||||
},
|
||||
assert: {
|
||||
...
|
||||
},
|
||||
},
|
||||
```
|
||||
|
||||
To make sure the [Accessibility Github workflow](https://github.com/backstage/backstage/blob/master/.github/workflows/verify_accessibility.yml) is running when changes are made to your plugin folders, modify the [list of paths](https://github.com/backstage/backstage/blob/10759b6ad2561bd86183ad940256f9a309c7a6b0/.github/workflows/verify_accessibility.yml#L7-L16).
|
||||
To make sure the [Accessibility GitHub workflow](https://github.com/backstage/backstage/blob/master/.github/workflows/verify_accessibility.yml) is running when changes are made to your plugin folders, modify the [list of paths](https://github.com/backstage/backstage/blob/10759b6ad2561bd86183ad940256f9a309c7a6b0/.github/workflows/verify_accessibility.yml#L7-L16).
|
||||
|
||||
### Run the Lighthouse CLI locally when developing new features
|
||||
|
||||
If you want to use the Lighthouse CLI and run the checks based on the config you can use the following command:
|
||||
|
||||
```
|
||||
```shell
|
||||
yarn dlx @lhci/cli@0.11.x autorun
|
||||
```
|
||||
|
||||
|
||||
@@ -41,14 +41,18 @@ auth:
|
||||
secret: ${AUTH_SESSION_SECRET}
|
||||
```
|
||||
|
||||
The Auth0 provider is a structure with three configuration keys:
|
||||
The Auth0 provider is a structure with these configuration keys:
|
||||
|
||||
- `clientId`: The Application client ID, found on the Auth0 Application page
|
||||
- `clientSecret`: The Application client secret, found on the Auth0 Application
|
||||
page
|
||||
- `domain`: The Application domain, found on the Auth0 Application page
|
||||
|
||||
Because Auth0 requires a session you need to give the session a secret key.
|
||||
It additionally relies on the following configuration to function:
|
||||
|
||||
- `session.secret`: The session secret is a key used for signing and/or encrypting cookies set by the application to maintain session state. In this case, 'your session secret' should be replaced with a long, complex, and unique string that only your application knows.
|
||||
|
||||
Auth0 requires a session, so you need to give the session a secret key.
|
||||
|
||||
## Optional Configuration
|
||||
|
||||
|
||||
@@ -20,8 +20,10 @@ The provider configuration can be added to your `app-config.yaml` under the root
|
||||
|
||||
```yaml title="app-config.yaml"
|
||||
auth:
|
||||
environment: development
|
||||
providers:
|
||||
oauth2Proxy: {}
|
||||
oauth2Proxy:
|
||||
development: {}
|
||||
```
|
||||
|
||||
Right now no configuration options are supported, but the empty object is needed
|
||||
@@ -58,6 +60,8 @@ providerFactories: {
|
||||
},
|
||||
```
|
||||
|
||||
[An example on how to sign a user in without a matching user](https://github.com/backstage/backstage/blob/master/packages/backend/src/plugins/auth.ts)
|
||||
|
||||
## Adding the provider to the Backstage frontend
|
||||
|
||||
It is recommended to use the `ProxiedSignInPage` for this provider, which is
|
||||
|
||||
@@ -61,11 +61,11 @@ All of these services can be replaced with your own implementations if you need
|
||||
For example, let's say we want to customize the core configuration service to enable remote configuration loading. That would look something like this:
|
||||
|
||||
```ts
|
||||
import { configServiceFactory } from '@backstage/backend-app-api';
|
||||
import { rootConfigServiceFactory } from '@backstage/backend-app-api';
|
||||
|
||||
const backend = createBackend({
|
||||
services: [
|
||||
configServiceFactory({
|
||||
rootConfigServiceFactory({
|
||||
remote: { reloadIntervalSeconds: 60 },
|
||||
}),
|
||||
],
|
||||
|
||||
@@ -37,7 +37,7 @@ describe('myPlugin', () => {
|
||||
|
||||
const { server } = await startTestBackend({
|
||||
features: [myPlugin()],
|
||||
services: [mockServices.config.factory({ data: fakeConfig })],
|
||||
services: [mockServices.rootConfig.factory({ data: fakeConfig })],
|
||||
});
|
||||
|
||||
const response = await request(server).get('/api/example/get-value');
|
||||
|
||||
@@ -183,11 +183,11 @@ There's additional configuration that you can optionally pass to setup the `conf
|
||||
You can configure these additional options by adding an override for the core service when calling `createBackend` like follows:
|
||||
|
||||
```ts
|
||||
import { configServiceFactory } from '@backstage/backend-app-api';
|
||||
import { rootConfigServiceFactory } from '@backstage/backend-app-api';
|
||||
|
||||
const backend = createBackend({
|
||||
services: [
|
||||
configServiceFactory({
|
||||
rootConfigServiceFactory({
|
||||
argv: [
|
||||
'--config',
|
||||
'/backstage/app-config.development.yaml',
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
id: flightcontrol
|
||||
title: Deploying with Flightcontrol
|
||||
sidebar_label: AWS Fargate via Flightcontrol
|
||||
description: Deploying Backstage to AWS Fargate via Flightcontrol
|
||||
---
|
||||
|
||||
This guide explains how to deploy Backstage to [Flightcontrol](https://www.flightcontrol.dev?ref=backstage), a platform that fully automates deployments to Amazon Web Services (AWS). Flightcontrol supports git-driven and image registry deployments.
|
||||
|
||||
Before you begin, make sure you have a [Flightcontrol account](https://app.flightcontrol.dev/signup?ref=backstage) and a [Github account](https://github.com/login) to follow this guide.
|
||||
|
||||
# Deployment Via Dashboard
|
||||
|
||||
1. Create a new project from the Flightcontrol Dashboard
|
||||
|
||||
2. Select the GitHub repo for your Backstage project
|
||||
|
||||
3. Select `GUI` as the config type:
|
||||
|
||||
4. Then, choose `+ Add Web Server (Fargate)` under Services before entering the following server information:
|
||||
|
||||
| Field Name | Value |
|
||||
| ----------------- | ----------------- |
|
||||
| Build Type | Custom Dockerfile |
|
||||
| Health Check Path | /catalog |
|
||||
| Port | 7007 |
|
||||
|
||||
5. Click `Create Project` and complete any required steps (like linking your AWS account).
|
||||
|
||||
# Deployment via Code
|
||||
|
||||
1. Create a new project from the Flightcontrol Dashboard
|
||||
|
||||
2. Select the GitHub repo for your Backstage project
|
||||
|
||||
3. Select the `flightcontrol.json` Config Type.
|
||||
|
||||
```json filename="flightcontrol.json"
|
||||
{
|
||||
"$schema": "https://app.flightcontrol.dev/schema.json",
|
||||
"environments": [
|
||||
{
|
||||
"id": "backstage",
|
||||
"name": "Backstage",
|
||||
"region": "us-west-2",
|
||||
"source": {
|
||||
"branch": "main"
|
||||
},
|
||||
"services": [
|
||||
{
|
||||
"id": "backstage",
|
||||
"name": "Backstage",
|
||||
"type": "fargate",
|
||||
"buildType": "docker",
|
||||
"dockerfilePath": "Dockerfile",
|
||||
"dockerContext": ".",
|
||||
"healthCheckPath": "/catalog",
|
||||
"cpu": 0.5,
|
||||
"memory": 1,
|
||||
"domain": "backstage.yourapp.com",
|
||||
"port": 7007,
|
||||
"minInstances": 1,
|
||||
"maxInstances": 1
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
# Databases and Redis
|
||||
|
||||
If you need a database or Redis for your Backstage plugins, you can easily add those to your Flightcontrol deployment. For more information, see [the flightcontrol docs](https://www.flightcontrol.dev/docs/guides/flightcontrol/using-code?ref=backstage#redis).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- [Flightcontrol Documentation](https://www.flightcontrol.dev/docs?ref=backstage)
|
||||
- [Troubleshooting](https://www.flightcontrol.dev/docs/troubleshooting?ref=backstage)
|
||||
@@ -64,7 +64,7 @@ The recommended approach would be to represent information in catalog-info files
|
||||
|
||||
**Naming strategies:**
|
||||
|
||||
- Ldap: Internal ldap usernames as entity names. e.g., owner: user:myuser or user: my-team-name.
|
||||
- Ldap: Internal ldap usernames as entity names. e.g., owner: user:my-user or user: my-team-name.
|
||||
|
||||
**Ownership strategies:**
|
||||
|
||||
|
||||
@@ -978,9 +978,9 @@ way.
|
||||
The entries of this array are
|
||||
[entity references](https://backstage.io/docs/features/software-catalog/references).
|
||||
|
||||
| [`kind`](#apiversion-and-kind-required) | Default [`namespace`](#namespace-optional) | Generated [relation](well-known-relations.md) type |
|
||||
| --------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------- |
|
||||
| [`Group`](#kind-group) (default) | Same as this entity, typically `default` | [`hasMember`, and reverse `memberOf`](well-known-relations.md#memberof-and-hasmember) |
|
||||
| [`kind`](#apiversion-and-kind-required) | Default [`namespace`](#namespace-optional) | Generated [relation](well-known-relations.md) type |
|
||||
| --------------------------------------- | ------------------------------------------ | --------------------------------------------------------------------------------- |
|
||||
| [`Group`](#kind-group) (default) | Same as this entity, typically `default` | [`parentOf`, and reverse `childOf`](well-known-relations.md#parentof-and-childof) |
|
||||
|
||||
### `spec.members` [optional]
|
||||
|
||||
|
||||
@@ -207,5 +207,9 @@ scaffolder backend:
|
||||
| Azure Pipeline Actions | [scaffolder-backend-module-azure-pipelines](https://www.npmjs.com/package/@parfuemerie-douglas/scaffolder-backend-module-azure-pipelines) | [Parfümerie Douglas](https://github.com/Parfuemerie-Douglas) |
|
||||
| Azure Repository Actions | [scaffolder-backend-module-azure-repositories](https://www.npmjs.com/package/@parfuemerie-douglas/scaffolder-backend-module-azure-repositories) | [Parfümerie Douglas](https://github.com/Parfuemerie-Douglas) |
|
||||
| Snyk Import Project | [plugin-scaffolder-backend-module-snyk](https://www.npmjs.com/package/@ma11hewthomas/plugin-scaffolder-backend-module-snyk) | [Matthew Thomas](https://github.com/Ma11hewThomas) |
|
||||
| JSON Merge Actions | [plugin-scaffolder-json-merge-actions](https://www.npmjs.com/package/@mdude2314/backstage-plugin-scaffolder-json-merge-actions) | [Drew Hill](https://github.com/arhill05) |
|
||||
| NPM Actions | [plugin-scaffolder-npm-actions](https://www.npmjs.com/package/@mdude2314/backstage-plugin-scaffolder-npm-actions) | [Drew Hill](https://github.com/arhill05) |
|
||||
| Slack Actions | [plugin-scaffolder-backend-module-slack](https://www.npmjs.com/package/@mdude2314/backstage-plugin-scaffolder-backend-module-slack) | [Drew Hill](https://github.com/arhill05) |
|
||||
| Microsoft Teams Actions | [plugin-scaffolder-backend-module-ms-teams](https://www.npmjs.com/package/@grvpandey11/backstage-plugin-scaffolder-backend-module-ms-teams) | [Gaurav Pandey](https://github.com/grvpandey11) |
|
||||
|
||||
Have fun! 🚀
|
||||
|
||||
@@ -89,10 +89,8 @@ export const validateKebabCaseValidation = (
|
||||
then please use `scaffolderPlugin.provide` from there instead and export it part of your `plugin.ts` rather than re-using the `scaffolder.plugin`.
|
||||
*/
|
||||
|
||||
import {
|
||||
scaffolderPlugin,
|
||||
createScaffolderFieldExtension,
|
||||
} from '@backstage/plugin-scaffolder';
|
||||
import { scaffolderPlugin } from '@backstage/plugin-scaffolder';
|
||||
import { createScaffolderFieldExtension } from '@backstage/plugin-scaffolder-react';
|
||||
import {
|
||||
ValidateKebabCase,
|
||||
validateKebabCaseValidation,
|
||||
@@ -133,7 +131,7 @@ Should look something like this instead:
|
||||
|
||||
```tsx
|
||||
import { ValidateKebabCaseFieldExtension } from './scaffolder/ValidateKebabCase';
|
||||
import { ScaffolderFieldExtensions } from '@backstage/plugin-scaffolder';
|
||||
import { ScaffolderFieldExtensions } from '@backstage/plugin-scaffolder-react';
|
||||
|
||||
const routes = (
|
||||
<FlatRoutes>
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Writing custom step layouts
|
||||
description: How to override the default step form layout
|
||||
---
|
||||
|
||||
Every form in each step rendered in the frontend uses the default form layout from [react-json-schema-form](https://react-jsonschema-form.readthedocs.io/). It is possible to override this behaviour by supplying a `ui:ObjectFieldTemplate` property for a particular step:
|
||||
Every form in each step rendered in the frontend uses the default form layout from [react-jsonschema-form](https://rjsf-team.github.io/react-jsonschema-form/docs/). It is possible to override this behaviour by supplying a `ui:ObjectFieldTemplate` property for a particular step:
|
||||
|
||||
```yaml
|
||||
parameters:
|
||||
@@ -12,7 +12,7 @@ parameters:
|
||||
ui:ObjectFieldTemplate: TwoColumn
|
||||
```
|
||||
|
||||
This is the same [field](https://react-jsonschema-form.readthedocs.io/en/latest/advanced-customization/custom-templates/#objectfieldtemplate) used by [react-json-schema-form](https://react-jsonschema-form.readthedocs.io/) but we need to add a couple of steps to ensure that the string value of `TwoColumn` above is resolved to a react component.
|
||||
This is the same [field](https://rjsf-team.github.io/react-jsonschema-form/docs/advanced-customization/custom-templates#objectfieldtemplate) used by [react-jsonschema-form](https://rjsf-team.github.io/react-jsonschema-form/docs/) but we need to add a couple of steps to ensure that the string value of `TwoColumn` above is resolved to a react component.
|
||||
|
||||
## Registering a React component as a custom step layout
|
||||
|
||||
|
||||
@@ -499,6 +499,7 @@ template. These follow the same standard format:
|
||||
- id: fetch-base # A unique id for the step
|
||||
name: Fetch Base # A title displayed in the frontend
|
||||
if: ${{ parameters.name }} # Optional condition, skip the step if not truthy
|
||||
each: ${{ parameters.iterable }} # Optional iterable, run the same step multiple times
|
||||
action: fetch:template # An action to call
|
||||
input: # Input that is passed as arguments to the action handler
|
||||
url: ./template
|
||||
@@ -510,6 +511,27 @@ By default we ship some [built in actions](./builtin-actions.md) that you can
|
||||
take a look at, or you can
|
||||
[create your own custom actions](./writing-custom-actions.md).
|
||||
|
||||
When `each` is provided, the current iteration value is available in the `${{ each }}` input.
|
||||
|
||||
Examples:
|
||||
|
||||
```yaml
|
||||
each: ['apples', 'oranges']
|
||||
input:
|
||||
values:
|
||||
fruit: ${{ each.value }}
|
||||
```
|
||||
|
||||
```yaml
|
||||
each: [{ name: 'apple', count: 3 }, { name: 'orange', count: 1 }]
|
||||
input:
|
||||
values:
|
||||
fruit: ${{ each.value.name }}
|
||||
count: ${{ each.value.count }}
|
||||
```
|
||||
|
||||
When `each` is used, the outputs of a repeated step are returned as an array of outputs from each iteration.
|
||||
|
||||
## Outputs
|
||||
|
||||
Each individual step can output some variables that can be used in the
|
||||
|
||||
@@ -188,15 +188,12 @@ import {
|
||||
} from '@backstage/plugin-techdocs';
|
||||
import { Entity } from '@backstage/catalog-model';
|
||||
|
||||
import {
|
||||
EntityListDocsGrid,
|
||||
DocsGroupConfig,
|
||||
} from '@backstage/plugin-techdocs';
|
||||
import { EntityListDocsGrid } from '@backstage/plugin-techdocs';
|
||||
|
||||
export type CustomTechDocsHomeProps = {
|
||||
groups?: Array<{
|
||||
title: React.ReactNode;
|
||||
filterPredicate: (entity: Entity) => boolean;
|
||||
filterPredicate: ((entity: Entity) => boolean) | string;
|
||||
}>;
|
||||
};
|
||||
|
||||
|
||||
+12
-12
@@ -2,25 +2,25 @@
|
||||
id: glossary
|
||||
title: Backstage Glossary
|
||||
# prettier-ignore
|
||||
description: List of all the terms, abbreviations, and phrases used in Backstage, together with their explanations.
|
||||
description: List of terms, abbreviations, and phrases used in Backstage, together with their explanations.
|
||||
---
|
||||
|
||||
The Backstage Glossary lists all the terms, abbreviations, and phrases used in
|
||||
The Backstage Glossary lists terms, abbreviations, and phrases used in
|
||||
Backstage, together with their explanations. We encourage you to use the
|
||||
terminology below for clarity and consistency when discussing Backstage.
|
||||
|
||||
### Authentication Glossary
|
||||
|
||||
This [page](../auth/glossary.md) directs to the terms and phrases related to
|
||||
authentication and identity section of Backstage.
|
||||
See also [Authentication Glossary](../auth/glossary.md), a separate glossary of terms and phrases
|
||||
specifically related to the authentication and identity section of Backstage.
|
||||
|
||||
### Backstage User Profiles
|
||||
|
||||
There are three main user profiles for Backstage: the integrator, the
|
||||
contributor, and the software engineer.
|
||||
contributor, and the end user (typically a software engineer).
|
||||
|
||||
| Term | Explanation |
|
||||
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Integrator | The **integrator** hosts the Backstage app and configures which plugins are available to use in the app. |
|
||||
| Contributor | The **contributor** adds functionality to the app by writing plugins. |
|
||||
| Software Engineer | The **software engineer** uses the app's functionality and interacts with its plugins. In practice, this profile covers the various roles that help deliver software, from the Software Engineer themselves, to Designers, Data Scientists, Product Owners, Engineering Managers, etc. |
|
||||
| Term | Explanation |
|
||||
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Integrator | The **integrator** hosts the Backstage app and configures which plugins are available to use in the app. |
|
||||
| Contributor | The **contributor** adds functionality to the app by writing plugins. |
|
||||
| End user | The **end user** uses the app's functionality and interacts with its plugins. This profile covers the various roles that help deliver software. The typical end user is a **software engineer**, but users might also consider themselves _designers_, _data scientists_, _product owners_, _engineering managers_, _technical writers_, and so on. |
|
||||
| Software engineer | The **software engineer** is an **end user** who uses the app's functionality and interacts with its plugins in the course of writing and documenting code. This user is more likely to embed documentation in the code files they produce, and create rough drafts of conceptual pages in collaboration with a **technical writer** or _technical editor_. |
|
||||
| Technical writer | The **technical writer** is an **end user** who uses the app's functionality and interacts with its plugins in the course of writing and editing documentation. This user is more likely to produce and customize templates and produce conceptual pages to supplement documentation embedded in code files. |
|
||||
|
||||
@@ -36,7 +36,7 @@ Example:
|
||||
```yaml
|
||||
# in app-config.yaml
|
||||
proxy:
|
||||
simple-example: http://simple.example.com:8080
|
||||
/simple-example: http://simple.example.com:8080
|
||||
'/larger-example/v1':
|
||||
target: http://larger.example.com:8080/svc.v1
|
||||
headers:
|
||||
|
||||
@@ -84,4 +84,4 @@ Below you can find a list of links and references to help you learn about and st
|
||||
- [Changelog](https://github.com/backstage/backstage/tree/master/docs/releases/v1.16.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://mailchi.mp/spotify/backstage-community) if you want to be informed about what is happening in the world of Backstage.
|
||||
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.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,72 @@
|
||||
---
|
||||
id: v1.17.0
|
||||
title: v1.17.0
|
||||
description: Backstage Release v1.17.0
|
||||
---
|
||||
|
||||
These are the release notes for the v1.17.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
|
||||
|
||||
### Changes to the New Backend System
|
||||
|
||||
For this release we had another look at the new backend system, in particular how well it fits together with the concept of plugin installation without code modification, and we identified a number of breaking changes that we wanted to make.
|
||||
|
||||
We have removed the ability to define options for plugins and modules, and force them to be optional for services. Options have been moved either to static configuration or extension points, and modules now also have the ability to register extension points.
|
||||
|
||||
Service factories are now considered `BackendFeature`s and are installed via `backend.add(...)` rather than via the `services` option, which has been removed.
|
||||
|
||||
The configuration service has also been renamed to `rootConfig` in order to match other root-scoped services and make space for a potential plugin-scoped configuration service in the future.
|
||||
|
||||
The shared environments concept has been removed. We are still interested in having some way to define reusable presets in the new system, but shared environments were too limited.
|
||||
|
||||
We expect these to be the last broad breaking changes to the new backend system, and are likely to start encouraging use of it in the next release.
|
||||
|
||||
### Catalog Telemetry with Processing Tracing
|
||||
|
||||
The Catalog has been instrumented with some simple OpenTelemetry Spans so you can now dig into the processing loop and see it in action using tracing.
|
||||
|
||||
Contributed by [@mikebryant](https://github.com/mikebryant) in [#17534](https://github.com/backstage/backstage/pull/17534)
|
||||
|
||||
### New `each` property for Scaffolder Actions
|
||||
|
||||
You can now define an `each` iterable in the `steps` for a template, which will run a given action for each entry in the iterable.
|
||||
|
||||
Contributed by [@alexef](https://github.com/alexef) in [#18157](https://github.com/backstage/backstage/pull/18157)
|
||||
|
||||
### Updated proxy configuration
|
||||
|
||||
The shape of the proxy plugin configuration has been changed in order to make space for additional keys. Rather than defining the proxy endpoints directly under `proxy`, they should now be defined at `proxy.endpoints` instead.
|
||||
|
||||
### OpenAPI Support for Backend Plugins
|
||||
|
||||
You can now use OpenAPI specs to generate typed routers for your backend plugins with request validation using `createOpenApiRouter()`. There’s been some movement to support this for some of the plugins in the monorepo like `todo`, `search` and `catalog`.
|
||||
|
||||
Contributed by [@sennyeya](https://github.com/sennyeya) in [#17875](https://github.com/backstage/backstage/pull/17875)
|
||||
|
||||
### New plugin: `@backstage/plugin-catalog-backend-module-gcp`
|
||||
|
||||
Allows ingestion of GKE Clusters as Resources into the Catalog. Contributed by [@mclarke47](https://github.com/mclarke47) in [#18759](https://github.com/backstage/backstage/pull/18759)
|
||||
|
||||
## 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.17.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.
|
||||
Reference in New Issue
Block a user