Merge branch 'backstage:master' into daan/sort-flags
This commit is contained in:
daan
@@ -0,0 +1,10 @@
|
||||
---
|
||||
'@backstage/plugin-tech-insights': patch
|
||||
---
|
||||
|
||||
Added the possibility to customize the check description in the scorecard component.
|
||||
|
||||
- The `CheckResultRenderer` type now exposes an optional `description` method that allows to overwrite the description with a different string or a React component for a provided check result.
|
||||
|
||||
Until now only the `BooleanCheck` element could be overridden, but from now on it's also possible to override the description for a check.
|
||||
As an example, the description could change depending on the check result. Refer to the [README](https://github.com/backstage/backstage/blob/master/plugins/tech-insights/README.md#adding-custom-rendering-components) file for more details
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-test-utils': patch
|
||||
---
|
||||
|
||||
Added `POSTGRES_11` and `POSTGRES_12` as supported test database IDs.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
---
|
||||
|
||||
Fix case GitLab workspace is a nested subgroup
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-github-pull-requests-board': patch
|
||||
---
|
||||
|
||||
The `EntityTeamPullRequestsContent` and `EntityTeamPullRequestsCard` support the ability to view the labels/tags added to each PR
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-search': patch
|
||||
---
|
||||
|
||||
Fixed 404 Error when fetching search results due to URL encoding changes
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-common': patch
|
||||
---
|
||||
|
||||
Remove the direct dependency on deprecated "request" library
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/plugin-kubernetes-backend': minor
|
||||
---
|
||||
|
||||
Allow fetching pod metrics limited by a `labelSelector`.
|
||||
|
||||
This is used by the Kubernetes tab on a components' page and leads to much smaller responses being received from Kubernetes, especially with larger Kubernetes clusters.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-explore': patch
|
||||
---
|
||||
|
||||
Make sure that the first support button row does not break across lines
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': patch
|
||||
---
|
||||
|
||||
Bumped create-app version.
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
'@backstage/app-defaults': patch
|
||||
---
|
||||
|
||||
Added a System Icon for resource entities.
|
||||
This can be obtained using:
|
||||
|
||||
```ts
|
||||
useApp().getSystemIcon('kind:resource');
|
||||
```
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-openapi-utils': patch
|
||||
---
|
||||
|
||||
Adjusted README accordingly after the generated output now has a `.generated.ts` extension
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-kubernetes': patch
|
||||
---
|
||||
|
||||
Omit managed fields in the Kubernetes resource YAML display.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
---
|
||||
|
||||
Adjusted the OpenAPI schema file name according to the new structure
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/integration': patch
|
||||
---
|
||||
|
||||
Fixed a bug where the wrong credentials would be selected when using multiple GitHub app integrations.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-app-api': minor
|
||||
---
|
||||
|
||||
The analytics' `navigate` event will now include the route parameters as attributes of the navigate event
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/repo-tools': minor
|
||||
---
|
||||
|
||||
Generated OpenAPI files now have a `.generated.ts` file name and a warning header at the top, to highlight that they should not be edited by hand.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-jenkins-backend': patch
|
||||
---
|
||||
|
||||
Fix handling of slashes in branch names
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-graph': patch
|
||||
---
|
||||
|
||||
Expose all `EntityRelationsGraphProps` to Catalog Graph Page
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
'@backstage/plugin-search-react': minor
|
||||
'@backstage/plugin-search': minor
|
||||
---
|
||||
|
||||
Add close button & improve search input.
|
||||
|
||||
MUI's Paper wrapping the SearchBar in the SearchPage was removed, we recommend users update their apps accordingly.
|
||||
|
||||
SearchBarBase's TextField's label support added & aria-label uses label string if present, tests relying on the default placeholder value should still work unless custom placeholder was given.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-analytics-module-ga4': minor
|
||||
---
|
||||
|
||||
Plugin provides Backstage Analytics API for Google Analytics 4. Once installed and configured, analytics events will be sent to GA4 as your users navigate and use your Backstage instance
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-home': patch
|
||||
---
|
||||
|
||||
Bump to using the later v5 versions of `@rjsf/*`
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-github': patch
|
||||
---
|
||||
|
||||
Fixed bug in queryWithPaging that caused secondary rate limit errors in GitHub with organizations having more than 1000 repositories. This change makes one request per second to avoid concurrency issues.
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
'@backstage/plugin-kubernetes': minor
|
||||
---
|
||||
|
||||
Added Pod logs components for Kubernetes plugin
|
||||
|
||||
**BREAKING**: `kubernetesProxyApi` for custom plugins built with components from the Kubernetes plugin apis, `kubernetesProxyApi` should be added to the plugin's API list.
|
||||
|
||||
```
|
||||
...
|
||||
export const kubernetesPlugin = createPlugin({
|
||||
id: 'kubernetes',
|
||||
apis: [
|
||||
...
|
||||
createApiFactory({
|
||||
api: kubernetesProxyApiRef,
|
||||
deps: {
|
||||
kubernetesApi: kubernetesApiRef,
|
||||
},
|
||||
factory: ({ kubernetesApi }) =>
|
||||
new KubernetesProxyClient({
|
||||
kubernetesApi,
|
||||
}),
|
||||
}),
|
||||
```
|
||||
|
||||
**BREAKING**: `KubernetesDrawer` is now called `KubernetesStructuredMetadataTableDrawer` so that we can do more than just show `StructuredMetadataTable`
|
||||
|
||||
`import { KubernetesDrawer } from "@backstage/plugin-kubernetes"`
|
||||
|
||||
should now be:
|
||||
|
||||
`import { KubernetesStructuredMetadataTableDrawer } from "@backstage/plugin-kubernetes"`
|
||||
+48
-2
@@ -219,7 +219,53 @@
|
||||
"@backstage/plugin-user-settings-backend": "0.1.8",
|
||||
"@backstage/plugin-vault": "0.1.11",
|
||||
"@backstage/plugin-vault-backend": "0.3.0",
|
||||
"@backstage/plugin-xcmetrics": "0.2.37"
|
||||
"@backstage/plugin-xcmetrics": "0.2.37",
|
||||
"@backstage/plugin-analytics-module-ga4": "0.0.0"
|
||||
},
|
||||
"changesets": []
|
||||
"changesets": [
|
||||
"afraid-shirts-train",
|
||||
"backend-like-a-tattoo",
|
||||
"beige-tigers-matter",
|
||||
"brown-eyes-yell",
|
||||
"calm-wolves-taste",
|
||||
"chilly-fireants-type",
|
||||
"clean-lobsters-brake",
|
||||
"cold-drinks-exercise",
|
||||
"create-app-1682437922",
|
||||
"curvy-months-appear",
|
||||
"dry-boats-sniff",
|
||||
"dull-wombats-stare",
|
||||
"eighty-olives-live",
|
||||
"fifty-laws-count",
|
||||
"five-tigers-whisper",
|
||||
"fresh-moons-unite",
|
||||
"funny-trains-sniff",
|
||||
"good-lions-approve",
|
||||
"green-cheetahs-cover",
|
||||
"healthy-ladybugs-chew",
|
||||
"honest-countries-deny",
|
||||
"hungry-foxes-divide",
|
||||
"lazy-keys-work",
|
||||
"mighty-bears-glow",
|
||||
"mighty-cows-greet",
|
||||
"modern-pumpkins-join",
|
||||
"moody-lizards-beam",
|
||||
"nine-ties-smoke",
|
||||
"olive-turkeys-switch",
|
||||
"polite-dingos-train",
|
||||
"pretty-gifts-greet",
|
||||
"quick-flies-guess",
|
||||
"red-cheetahs-invite",
|
||||
"rotten-chefs-jog",
|
||||
"serious-hornets-remember",
|
||||
"six-mails-shout",
|
||||
"slimy-turkeys-return",
|
||||
"soft-readers-exist",
|
||||
"swift-fishes-run",
|
||||
"tame-games-rule",
|
||||
"thick-parents-pump",
|
||||
"tough-moles-whisper",
|
||||
"unlucky-plants-give",
|
||||
"warm-lamps-tease"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-app-api': patch
|
||||
---
|
||||
|
||||
Added `FrontendHostDiscovery` for config driven discovery implementation
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-octopus-deploy': minor
|
||||
---
|
||||
|
||||
Added support for Octopus Deploy spaces. The octopus.com/project-id annotation can now (optionally) be prefixed by a space identifier, for example. Spaces-1/Projects-102.
|
||||
Also note that some of this plugins exported API's have changed to accommodate this change, changing from separate arguments to a single object.
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-react': patch
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
---
|
||||
|
||||
Improvements to the `scaffolder/next` buttons UX:
|
||||
|
||||
- Added padding around the "Create" button in the `Stepper` component
|
||||
- Added a button bar that includes the "Cancel" and "Start Over" buttons to the `OngoingTask` component. The state of these buttons match their existing counter parts in the Context Menu
|
||||
- Added a "Show Button Bar"/"Hide Button Bar" item to the `ContextMenu` component
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-circleci': patch
|
||||
---
|
||||
|
||||
Hide empty time field data for queued builds which haven't started yet
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
'@backstage/plugin-permission-node': patch
|
||||
---
|
||||
|
||||
`createPermissionIntegrationRouter` now accepts rules and permissions for multiple resource types. Example:
|
||||
|
||||
```typescript
|
||||
createPermissionIntegrationRouter({
|
||||
resources: [
|
||||
{
|
||||
resourceType: 'resourceType-1',
|
||||
permissions: permissionsResourceType1,
|
||||
rules: rulesResourceType1,
|
||||
},
|
||||
{
|
||||
resourceType: 'resourceType-2',
|
||||
permissions: permissionsResourceType2,
|
||||
rules: rulesResourceType2,
|
||||
},
|
||||
],
|
||||
});
|
||||
```
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-common': patch
|
||||
---
|
||||
|
||||
Added `HostDiscovery` to supersede deprecated `SingleHostDiscovery` (deprecated due to name)
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': patch
|
||||
---
|
||||
|
||||
Bump minimum required version of `vm2` to be 3.9.17
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': patch
|
||||
---
|
||||
|
||||
Pin some octokit dependencies to avoid failing typescript build under `tsc:full`
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': patch
|
||||
'@backstage/plugin-scaffolder-node': patch
|
||||
---
|
||||
|
||||
Update typing for `RouterOptions::actions` and `ScaffolderActionsExtensionPoint::addActions` to allow any kind of action being assigned to it.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-tech-radar': patch
|
||||
---
|
||||
|
||||
Added the ability to display a timeline to each entry in the details box
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
Start capturing sidebar click events in analytics by default.
|
||||
@@ -8,10 +8,6 @@ jobs:
|
||||
deploy-microsite-and-storybook:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [16.x]
|
||||
|
||||
env:
|
||||
CI: true
|
||||
NODE_OPTIONS: --max-old-space-size=8192
|
||||
@@ -20,10 +16,10 @@ jobs:
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
- name: use node.js 18.x
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: ${{ matrix.node-version }}
|
||||
node-version: 18.x
|
||||
registry-url: https://registry.npmjs.org/ # Needed for auth
|
||||
|
||||
# We avoid caching in this workflow, as we're running an install of both the top-level
|
||||
|
||||
@@ -9,10 +9,6 @@ jobs:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [16.x]
|
||||
|
||||
env:
|
||||
CI: true
|
||||
NODE_OPTIONS: --max-old-space-size=4096
|
||||
@@ -20,15 +16,15 @@ jobs:
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
- name: use node.js 18.x
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: ${{ matrix.node-version }}
|
||||
node-version: 18.x
|
||||
registry-url: https://registry.npmjs.org/ # Needed for auth
|
||||
- name: yarn install
|
||||
uses: backstage/actions/yarn-install@v0.6.3
|
||||
with:
|
||||
cache-prefix: ${{ runner.os }}-v${{ matrix.node-version }}
|
||||
cache-prefix: ${{ runner.os }}-v18.x
|
||||
|
||||
# No verification done here, only build & publish. If the master branch
|
||||
# is broken we will see that from those builds, but we still want to push nightly
|
||||
|
||||
@@ -10,22 +10,18 @@ jobs:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [16.x]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
- name: use node.js 18.x
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: ${{ matrix.node-version }}
|
||||
node-version: 18.x
|
||||
registry-url: https://registry.npmjs.org/ # Needed for auth
|
||||
- name: yarn install
|
||||
uses: backstage/actions/yarn-install@v0.6.3
|
||||
with:
|
||||
cache-prefix: ${{ runner.os }}-v${{ matrix.node-version }}
|
||||
cache-prefix: ${{ runner.os }}-v18.x
|
||||
|
||||
- name: Create Snyk report
|
||||
uses: snyk/actions/node@master
|
||||
|
||||
@@ -8,10 +8,14 @@ on:
|
||||
paths-ignore:
|
||||
- 'lighthouserc.js'
|
||||
- '.github/workflows/verify_accessibility_core.yml'
|
||||
- 'plugins/catalog/**'
|
||||
- 'plugins/techdocs/**'
|
||||
- 'plugins/scaffolder/**'
|
||||
- 'plugins/search/**'
|
||||
- 'plugins/catalog/src/**'
|
||||
- 'plugins/catalog-react/src/**'
|
||||
- 'plugins/techdocs/src/**'
|
||||
- 'plugins/techdocs-react/src/**'
|
||||
- 'plugins/scaffolder/src/**'
|
||||
- 'plugins/scaffolder-react/src/**'
|
||||
- 'plugins/search/src/**'
|
||||
- 'plugins/search-react/src/**'
|
||||
|
||||
jobs:
|
||||
noop:
|
||||
|
||||
@@ -6,11 +6,14 @@ on:
|
||||
paths:
|
||||
- 'lighthouserc.js'
|
||||
- '.github/workflows/verify_accessibility_core.yml'
|
||||
- 'plugins/catalog/**'
|
||||
- 'plugins/techdocs/**'
|
||||
- 'plugins/scaffolder/**'
|
||||
- 'plugins/search/**'
|
||||
|
||||
- 'plugins/catalog/src/**'
|
||||
- 'plugins/catalog-react/src/**'
|
||||
- 'plugins/techdocs/src/**'
|
||||
- 'plugins/techdocs-react/src/**'
|
||||
- 'plugins/scaffolder/src/**'
|
||||
- 'plugins/scaffolder-react/src/**'
|
||||
- 'plugins/search/src/**'
|
||||
- 'plugins/search-react/src/**'
|
||||
jobs:
|
||||
lhci:
|
||||
name: Accessibility
|
||||
|
||||
@@ -13,10 +13,6 @@ jobs:
|
||||
noop:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [16.x]
|
||||
|
||||
name: Microsite
|
||||
steps:
|
||||
- run: echo NOOP
|
||||
|
||||
@@ -11,10 +11,6 @@ jobs:
|
||||
build-microsite:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [16.x]
|
||||
|
||||
env:
|
||||
CI: true
|
||||
NODE_OPTIONS: --max-old-space-size=8192
|
||||
@@ -24,10 +20,10 @@ jobs:
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
- name: use node.js 18.x
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: ${{ matrix.node-version }}
|
||||
node-version: 18.x
|
||||
|
||||
# Skip caching of microsite dependencies, it keeps the global cache size
|
||||
# smaller, which make Windows builds a lot faster for the rest of the project.
|
||||
|
||||
@@ -22,10 +22,6 @@ jobs:
|
||||
noop:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [16.x]
|
||||
|
||||
name: Storybook
|
||||
steps:
|
||||
- run: echo NOOP
|
||||
|
||||
@@ -243,3 +243,4 @@ _You can do this by using the [Adopter form](https://info.backstage.spotify.com/
|
||||
| [Chartboost](https://www.chartboost.com)| [@brucearctor](https://github.com/brucearctor), [@ArtemChekunov](https://github.com/ArtemChekunov) | We are building our internal develper portal on top of Backstage.|
|
||||
| [Quantum Metric](https://www.quantummetric.com/) | [Eric Irwin](https://www.linkedin.com/in/ericirwin1124/) | Backstage is used within our Developer Experience Platform (DXP) in order to increase self-service, standardization and discoverability across our Engineering teams. |
|
||||
| [VodafoneZiggo](https://www.vodafoneziggo.nl/) | [Peter Macdonald](https://github.com/Parsifal-M) | We use Backstage as our go-to platform for managing our internal tools and services. With Backstage, we can easily discover and access all the services we need to do our work, whether it's deploying code, managing infrastructure, or accessing documentation. We appreciate the standardized, consistent interface and the ability to easily create custom plugins to integrate with our existing workflows. Overall, Backstage is streamlining our internal operations and helps us work more efficiently as a team. |
|
||||
| [Volvo Cars](https://www.volvocars.com) | [Martin Wänerskär](https://github.com/martin-wanerskar) | Internal developer portal with intent to unify infrastructure tooling, services, and developer documentation under a single, easy-to-use interface. |
|
||||
+10
-5
@@ -37,8 +37,11 @@ app:
|
||||
|
||||
We can access the `baseUrl` using `config.getString('app.baseUrl')`. Because of
|
||||
this syntax, configuration keys are not allowed to contain dots. In fact,
|
||||
configuration keys are validated using the following RegEx:
|
||||
`/^[a-z][a-z0-9]*(?:[-_][a-z][a-z0-9]*)*$/i`.
|
||||
configuration keys are validated using the following regular expression:
|
||||
`/^[a-z][a-z0-9]*(?:[-_][a-z][a-z0-9]*)*$/i`. This basically means that keys
|
||||
must only contain the letters `a` through `z` and digits, in groups separated by
|
||||
dashes or underscores. Additionally, the very first character of each such group
|
||||
must be a letter, not a digit.
|
||||
|
||||
Another option of accessing the `baseUrl` value is to create a sub-view of the
|
||||
configuration, `config.getConfig('app').getString('baseUrl')`. When reading out
|
||||
@@ -62,8 +65,9 @@ each sub-view to be handled individually.
|
||||
|
||||
```ts
|
||||
for (const itemKey of config.keys('my-plugin.items')) {
|
||||
const itemConfig = config.getConfig(`my-plugin.items`).getConfig(key);
|
||||
const item = createItemFromConfig(itemConfig);
|
||||
const itemConfig = config.getConfig(`my-plugin.items`).getConfig(itemKey);
|
||||
const title = itemConfig.getString('title');
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
@@ -76,7 +80,8 @@ much more detailed and relevant error messages. For example, if
|
||||
`itemConfig.getString('title')` fails in the above example because a boolean was
|
||||
supplied, the user will receive an error message with the full path, e.g.
|
||||
`my-plugin.items.b.title`, as well as the name of the config file with the bad
|
||||
value.
|
||||
value. Conversely, if you try to access missing fields in raw JSON, you tend to
|
||||
end up with very technical and hard-to-understand type errors from javascript.
|
||||
|
||||
Note that no matter what method is used for reading out nested config, the same
|
||||
merging rules apply. You will always get the same value for any way of accessing
|
||||
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
id: authorizing-parameters-steps-and-actions
|
||||
title: 'Authorizing parameters, steps and actions'
|
||||
description: How to authorize part of a template
|
||||
---
|
||||
|
||||
The scaffolder plugin integrates with the Backstage [permission framework](../../permissions/overview.md), which allows you to control access to certain parameters and steps in your templates based on the user executing the template.
|
||||
|
||||
### Authorizing parameters and steps
|
||||
|
||||
To mark specific parameters or steps as requiring permission, add the `backstage:permissions` property to the parameter or step with one or more tags. For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: scaffolder.backstage.io/v1beta3
|
||||
kind: Template
|
||||
metadata:
|
||||
name: my_custom_template
|
||||
parameters:
|
||||
- title: Provide some simple information
|
||||
properties:
|
||||
title:
|
||||
title: Title
|
||||
type: string
|
||||
- title: Extra information
|
||||
properties:
|
||||
description:
|
||||
title: Description
|
||||
type: string
|
||||
backstage:permissions:
|
||||
tags:
|
||||
- secret
|
||||
steps:
|
||||
- id: step1
|
||||
name: First log
|
||||
action: debug:log
|
||||
input:
|
||||
message: hello
|
||||
- id: step2
|
||||
name: Log message
|
||||
action: debug:log
|
||||
input:
|
||||
message: hello
|
||||
backstage:permissions:
|
||||
tags:
|
||||
- secret
|
||||
```
|
||||
|
||||
In this example, the `description` parameter and the `step2` step are marked with the `secret` tag.
|
||||
|
||||
To conditionally authorize parameters and steps based on the user executing the template, [edit your permission policy](../../permissions/writing-a-policy.md), by targeting `templateParameterReadPermission` and `templateStepReadPermission` permissions, which are provided by the scaffolder plugin. For example:
|
||||
|
||||
```ts title="packages/backend/src/plugins/permission.ts"
|
||||
/* highlight-add-start */
|
||||
import {
|
||||
templateParameterReadPermission,
|
||||
templateStepReadPermission,
|
||||
} from '@backstage/plugin-scaffolder-common/alpha';
|
||||
import {
|
||||
createScaffolderActionConditionalDecision,
|
||||
scaffolderTemplateConditions,
|
||||
} from '@backstage/plugin-scaffolder-backend/alpha';
|
||||
/* highlight-add-end */
|
||||
|
||||
class ExamplePermissionPolicy implements PermissionPolicy {
|
||||
async handle(
|
||||
request: PolicyQuery,
|
||||
user?: BackstageIdentityResponse,
|
||||
): Promise<PolicyDecision> {
|
||||
/* highlight-add-start */
|
||||
if (
|
||||
isPermission(request.permission, templateParameterReadPermission) ||
|
||||
isPermission(request.permission, templateStepReadPermission)
|
||||
) {
|
||||
if (user?.identity.userEntityRef === 'user:default/spiderman')
|
||||
return createScaffolderTemplateConditionalDecision(request.permission, {
|
||||
not: scaffolderTemplateConditions.hasTag({ tag: 'secret' }),
|
||||
});
|
||||
}
|
||||
/* highlight-add-end */
|
||||
|
||||
return {
|
||||
result: AuthorizeResult.ALLOW,
|
||||
};
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In this example, the user `spiderman` is not authorized to read parameters or steps marked with the `secret` tag.
|
||||
|
||||
By combining this feature with restricting the ingestion of templates in the Catalog as recommended in our threat model, you can create a solid system to restrict certain actions.
|
||||
|
||||
### Authorizing actions
|
||||
|
||||
Similar to parameters and steps, the scaffolder plugin exposes permissions to restrict access to certain actions. This can be useful if you want to secure your templates.
|
||||
|
||||
To restrict access to a particular action, you can modify your permission policy as follows:
|
||||
|
||||
```ts title="packages/backend/src/plugins/permission.ts"
|
||||
/* highlight-add-start */
|
||||
import { actionExecutePermission } from '@backstage/plugin-scaffolder-common/alpha';
|
||||
import {
|
||||
createScaffolderActionConditionalDecision,
|
||||
scaffolderActionConditions,
|
||||
} from '@backstage/plugin-scaffolder-backend/alpha';
|
||||
/* highlight-add-end */
|
||||
|
||||
class ExamplePermissionPolicy implements PermissionPolicy {
|
||||
async handle(
|
||||
request: PolicyQuery,
|
||||
user?: BackstageIdentityResponse,
|
||||
): Promise<PolicyDecision> {
|
||||
/* highlight-add-start */
|
||||
if (isPermission(request.permission, actionExecutePermission)) {
|
||||
if (user?.identity.userEntityRef === 'user:default/spiderman') {
|
||||
return createScaffolderActionConditionalDecision(request.permission, {
|
||||
not: scaffolderActionConditions.hasActionId({
|
||||
actionId: 'debug:log',
|
||||
}),
|
||||
});
|
||||
}
|
||||
}
|
||||
/* highlight-add-end */
|
||||
|
||||
return {
|
||||
result: AuthorizeResult.ALLOW,
|
||||
};
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
With this permission policy, the user `spiderman` won't be able to execute the debug:log action.
|
||||
|
||||
You can also restrict the input provided to the action by combining multiple rules.
|
||||
In the example below, `spiderman` won't be able to execute debug:log when passing `{ "message": "not-this!" }` as action input:
|
||||
|
||||
```ts title="packages/backend/src/plugins/permission.ts"
|
||||
/* highlight-add-start */
|
||||
import { actionExecutePermission } from '@backstage/plugin-scaffolder-common/alpha';
|
||||
import {
|
||||
createScaffolderActionConditionalDecision,
|
||||
scaffolderActionConditions,
|
||||
} from '@backstage/plugin-scaffolder-backend/alpha';
|
||||
/* highlight-add-end */
|
||||
|
||||
class ExamplePermissionPolicy implements PermissionPolicy {
|
||||
async handle(
|
||||
request: PolicyQuery,
|
||||
user?: BackstageIdentityResponse,
|
||||
): Promise<PolicyDecision> {
|
||||
/* highlight-add-start */
|
||||
if (isPermission(request.permission, actionExecutePermission)) {
|
||||
if (user?.identity.userEntityRef === 'user:default/spiderman') {
|
||||
return createScaffolderActionConditionalDecision(request.permission, {
|
||||
not: {
|
||||
allOf: [
|
||||
scaffolderActionConditions.hasActionId({ actionId: 'debug:log' }),
|
||||
scaffolderActionConditions.hasProperty({
|
||||
key: 'message',
|
||||
value: 'not-this!',
|
||||
}),
|
||||
],
|
||||
},
|
||||
});
|
||||
}
|
||||
}
|
||||
/* highlight-add-end */
|
||||
|
||||
return {
|
||||
result: AuthorizeResult.ALLOW,
|
||||
};
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Although the rules exported by the scaffolder are simple, combining them can help you achieve more complex cases.
|
||||
@@ -400,15 +400,10 @@ As you've seen there are many ways that you can customize your Backstage app. Th
|
||||
For this example we'll show you how you can expand the sidebar with a sub-menu:
|
||||
|
||||
1. Open the `Root.tsx` file located in `packages/app/src/components/Root` as this is where the sidebar code lives
|
||||
2. Then we want to add the following imports for the icons:
|
||||
2. Then we want to add the following import for `useApp`:
|
||||
|
||||
```tsx title="packages/app/src/components/Root/Root.tsx"
|
||||
import ApiIcon from '@material-ui/icons/Extension';
|
||||
import ComponentIcon from '@material-ui/icons/Memory';
|
||||
import DomainIcon from '@material-ui/icons/Apartment';
|
||||
import ResourceIcon from '@material-ui/icons/Work';
|
||||
import SystemIcon from '@material-ui/icons/Category';
|
||||
import UserIcon from '@material-ui/icons/Person';
|
||||
import { useApp } from '@backstage/core-plugin-api';
|
||||
```
|
||||
|
||||
3. Then update the `@backstage/core-components` import like this:
|
||||
@@ -441,39 +436,39 @@ For this example we'll show you how you can expand the sidebar with a sub-menu:
|
||||
<SidebarSubmenuItem
|
||||
title="Domains"
|
||||
to="catalog?filters[kind]=domain"
|
||||
icon={DomainIcon}
|
||||
icon={useApp().getSystemIcon('kind:domain')}
|
||||
/>
|
||||
<SidebarSubmenuItem
|
||||
title="Systems"
|
||||
to="catalog?filters[kind]=system"
|
||||
icon={SystemIcon}
|
||||
icon={useApp().getSystemIcon('kind:system')}
|
||||
/>
|
||||
<SidebarSubmenuItem
|
||||
title="Components"
|
||||
to="catalog?filters[kind]=component"
|
||||
icon={ComponentIcon}
|
||||
icon={useApp().getSystemIcon('kind:component')}
|
||||
/>
|
||||
<SidebarSubmenuItem
|
||||
title="APIs"
|
||||
to="catalog?filters[kind]=api"
|
||||
icon={ApiIcon}
|
||||
icon={useApp().getSystemIcon('kind:api')}
|
||||
/>
|
||||
<SidebarDivider />
|
||||
<SidebarSubmenuItem
|
||||
title="Resources"
|
||||
to="catalog?filters[kind]=resource"
|
||||
icon={ResourceIcon}
|
||||
icon={useApp().getSystemIcon('kind:resource')}
|
||||
/>
|
||||
<SidebarDivider />
|
||||
<SidebarSubmenuItem
|
||||
title="Groups"
|
||||
to="catalog?filters[kind]=group"
|
||||
icon={GroupIcon}
|
||||
icon={useApp().getSystemIcon('kind:group')}
|
||||
/>
|
||||
<SidebarSubmenuItem
|
||||
title="Users"
|
||||
to="catalog?filters[kind]=user"
|
||||
icon={UserIcon}
|
||||
icon={useApp().getSystemIcon('kind:user')}
|
||||
/>
|
||||
</SidebarSubmenu>
|
||||
</SidebarItem>
|
||||
|
||||
@@ -38,6 +38,8 @@ In a typical Backstage setup, there is no boundary between plugins that run on t
|
||||
|
||||
The `UrlReader` facility is of particular interest for a secure Backstage configuration. In particular the `backend.reading.allow` configuration lists the hosts that you trust the backend to be able to read content from on behalf of users. It is extremely important that this list does not, for example, allow access to instance metadata endpoints of cloud providers, or other endpoints that your Backstage instance may have access to which contain sensitive information. In general it is recommended to keep the list minimal and only allow reading from required endpoints. The same concerns apply to custom implementations of the `UrlReader` interface, if you need to implement these through code.
|
||||
|
||||
Note that the `UrlReader` system operates with a service context and is not integrated with the Backstage permission system or other external access control mechanisms. This means users of your Backstage instance may be able to read external content which that individual should not have access to. For example, the `$text` placeholder in a `catalog-info.yaml` can be used to read contents from a source such as a GitHub repository that the user does not have direct access too. If this is a concern it is recommended to either disable or replace the resolvers in the catalog placeholder processor and similar features in any other plugin.
|
||||
|
||||
## Authentication
|
||||
|
||||
Backstage provides authentication of users through the `auth` plugin, which primarily acts as an authorization server for different OAuth 2.0 provider integrations. These integrations can both serve the purpose of signing users into Backstage, as well as providing delegated access to external resources, and are all subject to the common concerns of implementing secure OAuth 2.0 authorization servers. All auth provider integrations are disabled by default, and need to be enabled through configuration in order to be used. For each Backstage installation it is recommended to only enable the minimal set of providers that are in use by that instance.
|
||||
|
||||
@@ -54,7 +54,7 @@ installed, may be captured.
|
||||
|
||||
| Action | Subject | Other Notes |
|
||||
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `navigate` | The URL of the page that was navigated to. | |
|
||||
| `navigate` | The URL of the page that was navigated to. | The parameters of the current route will be included as attributes |
|
||||
| `click` | The text of the link that was clicked on. | The `to` attribute represents the URL clicked to. |
|
||||
| `create` | The `name` of the software being created; if no `name` property is requested by the given Software Template, then the string `new {templateName}` is used instead. | The context holds an `entityRef`, set to the template's ref (e.g. `template:default/template-name`). |
|
||||
| `search` | The search term entered in any search bar component. | The context holds `searchTypes`, representing `types` constraining the search. The `value` represents the total number of search results for the query. This may not be visible if the permission framework is being used. |
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
+1
-2
@@ -46,7 +46,6 @@ module.exports = {
|
||||
startServerReadyTimeout: 600000,
|
||||
numberOfRuns: 1,
|
||||
puppeteerScript: './.lighthouseci/scripts/guest-auth.js',
|
||||
startServerReadyPattern: 'Listening on :7007',
|
||||
},
|
||||
assert: {
|
||||
assertions: {
|
||||
@@ -54,7 +53,7 @@ module.exports = {
|
||||
'categories:pwa': 'off',
|
||||
'categories:best-practices': 'off',
|
||||
'categories:seo': 'off',
|
||||
'categories:accessibility': ['error', { minScore: 0.85 }],
|
||||
'categories:accessibility': ['error', { minScore: 0.95 }],
|
||||
},
|
||||
},
|
||||
},
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ It’s the first open source infrastructure platform by Spotify that allows you
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## As simple as writing a plugin.
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ authorImageURL: https://pbs.twimg.com/profile_images/121166861/6919c047c0d0edaac
|
||||
|
||||
Two days ago, we released the open source version of [Backstage](https://backstage.io/), our homegrown developer portal. And we learned a thing or two via the feedback we received. So, I wanted to take this opportunity to further explain what we’re trying to do with Backstage — and more importantly, what we want to give to the greater engineering community beyond Spotify.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## What’s the big infrastructure problem?
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ authorImageURL: https://pbs.twimg.com/profile_images/1224058798958088192/JPxS8uz
|
||||
|
||||
We’re proud to announce that our first internal plugin at Spotify has been open-sourced as part of Backstage. This plugin works with the newly open-sourced [lighthouse-audit-service](https://github.com/spotify/lighthouse-audit-service) to run and track Lighthouse audits for your websites.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## What is Lighthouse?
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ We want users to be able to create their own version of Backstage quickly and ea
|
||||
|
||||
In this blog post we’ll look at what a Backstage app is and how to create one using our [CLI](https://www.npmjs.com/package/@backstage/cli).
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## What is a Backstage app?
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ authorImageURL: https://avatars0.githubusercontent.com/bih
|
||||
|
||||
Just a few weeks ago, we released our internal plugin for [Lighthouse website audits] as our first open source plugin, so the whole community could use it. Today, we’re excited to add a new plugin to that list — say hello to the [Tech Radar plugin]!
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## What is Tech Radar?
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ authorImageURL: https://avatars2.githubusercontent.com/u/46946747
|
||||
|
||||
One of the great things about the open source community is once you put your work out there, you really never know where it might end up. That’s certainly the case here.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
When Weaveworks decided to build an X-ray diagnostics app to help fight COVID-19, they pulled together a lot of different open source resources — from projects big and small, built by both familiar tech partners and some brand new ones, too.
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ We released the open source version of Backstage a little less than two months a
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Progress so far
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ image: https://backstage.io/blog/assets/6/header.png
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## You asked, we listened
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ authorImageURL: https://avatars1.githubusercontent.com/u/1236238?s=460&v=4
|
||||
|
||||
Getting authentication right is important. It helps keep your platform safe, it’s one of the first things users will interact with, and there are many different authentication providers to support. To this end, we chose to use [Passport](http://www.passportjs.org/) to provide an easy-to-use, out-of-the-box experience that can be extended to your own, pre-existing authentication providers (known as strategies). The Auth APIs in Backstage serve two purposes: identify the user and provide a way for plugins to request access to third-party services on behalf of the user. We’ve already implemented Google and GitHub authentication to provide examples and to get you started.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## What is Passport?
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ authorURL: https://twitter.com/stalund
|
||||
<source src="/blog/assets/2020-08-05/feature.mp4" type="video/mp4" />
|
||||
</video>
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Balancing autonomy and standardization
|
||||
|
||||
+9
-3
@@ -7,10 +7,16 @@ authorURL: https://github.com/garyniemen
|
||||
|
||||
Since we [open sourced Backstage](https://backstage.io/blog/2020/03/16/announcing-backstage), one of the most requested features has been for a technical documentation plugin. Well, good news. The first open source version of TechDocs is here. Now let’s start collaborating and making it better, together.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/mOLCgdPw1iA" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen>
|
||||
</iframe>
|
||||
<iframe
|
||||
width="780"
|
||||
height="440"
|
||||
src="https://www.youtube.com/embed/mOLCgdPw1iA"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
Internally, we call it TechDocs. It’s the most used plugin at Spotify by far — accounting for about 20% of our Backstage traffic (even though it is just one of 130+ plugins). Its popularity is evidence of something simple: We made documentation so easy to create, find, and use — people actually use it.
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ authorURL: https://twitter.com/stalund
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
Backstage garnered quite a bit of interest from developers and organizations when it was first announced, and community interest continues to grow as plugins and new features are added with the open source community. We released the open source version of Backstage ‘early’. That was intentional. Because even though we’ve been using Backstage internally for years, we wanted the open source version to be developed with input and contributions from the community. And that’s exactly the product that’s going into the [CNCF Sandbox](https://www.cncf.io/sandbox-projects/) today.
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ authorURL: http://twitter.com/katherinemzhou
|
||||
|
||||
We are excited to launch the Backstage Design System, which includes a [Figma UI kit](https://www.figma.com/community/file/850673348101741100), a rich set of [reusable code components](http://backstage.io/storybook) on Storybook, and [Guidelines](https://backstage.io/docs/dls/design) for designers and developers as they build plugins for Backstage.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Not just the way it looks
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ Now you may be thinking, “Yeah, sure, that sounds nice and all, but how does B
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
Think of plugins as a mini version of an infrastructure tool or service — just the parts you need, made quick and easy. The advantage of using a Backstage plugin instead of a tool’s dedicated UI is that all your infrastructure is packaged into a “single pane of glass” instead of being spread out like independently built “islands”. Once you grow your infrastructure portfolio, the complexity really starts to add up. The Backstage plugin model allows you to add more tools without increasing the cognitive load for your users.
|
||||
|
||||
+9
-2
@@ -7,11 +7,18 @@ authorURL: https://twitter.com/janisa_a
|
||||
|
||||
How did Spotify save millions on cloud costs within a matter of months?? We made cost optimization just another part of the daily development process. Our newly open sourced [Cost Insights plugin](https://github.com/backstage/backstage/tree/master/plugins/cost-insights) makes a team’s cloud costs visible — and actionable — right inside Backstage. So engineers can see the impact of their cloud usage (down to a product and resource level) and make optimizations wherever and whenever it makes sense. By managing cloud costs from the ground up, you can make smarter decisions that let you continue to build and scale quickly, without wasting resources.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/YLAd5hdXR_Q" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
<iframe
|
||||
width="780"
|
||||
height="440"
|
||||
src="https://www.youtube.com/embed/YLAd5hdXR_Q"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
|
||||
Are we turning engineers into accountants? Nope, we’re just letting engineers do what they do best, in the place that feels natural to them: inside Backstage.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Why put a cost management tool in the hands of engineers?
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ authorURL: https://github.com/Rugvip
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
Backstage has a great and growing community of users and contributors. With so much valuable feedback, this inevitably means that sometimes we will go back and revise design decisions that introduce breaking changes. Furthermore, as we continue to ship new features and systems, we’ll continue this cycle of iterating, gathering feedback, and iterating again before reaching a stable API.
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ TLDR; We’re rethinking the Kubernetes developer experience with a new feature:
|
||||
|
||||
And since Backstage uses the native Kubernetes API, the feature works with whichever cloud provider (AWS, Azure, GCP, etc.) or managed service (OpenShift, IBM Cloud, GKE, etc.) you already use.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## The missing link between K8s and your service
|
||||
|
||||
+7
-4
@@ -8,7 +8,7 @@ authorURL: https://www.linkedin.com/in/austinlamon
|
||||
|
||||
One of the greatest strengths of Backstage also presents a never-ending challenge: Backstage is highly customizable and allows you to easily build a unique developer portal suited to your organization’s needs. The downside of this flexibility is that it can be hard to know where to start. Backstage can do so many things — integrating every part of your tech infrastructure and developer experience — but if you set off building a developer portal without a plan, it’s easy to get overwhelmed by all the possibilities. To help you form your plan, this post will detail how Spotify came to design our internal portal and recommend potential models for you to use when designing and building your own.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Infrastructure as tech culture
|
||||
|
||||
@@ -23,12 +23,14 @@ Spotify’s developers were facing three big challenges on a daily basis:
|
||||
- They needed to keep an eye on what squads around them might be building to ensure they could reuse systems when they needed to solve similar problems in the future.
|
||||
|
||||
In short, Spotify developers needed to continue building industry leading features at breakneck speed, while simultaneously maintaining a mental model for all the software at Spotify (oh, and help every new joiner develop that mental model as well!).
|
||||
<br/>
|
||||
|
||||
<br />
|
||||
|
||||
## Three jobs: Create, manage, explore
|
||||
|
||||
Around the same time, the [jobs to be done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done) framework was becoming popular and luckily, a few Spotifiers helped guide the vision for a _sense-making tool for developers_ toward using it. After user research and many failed attempts, we landed on three jobs Spotify developers needed to do consistently:
|
||||
<br/>
|
||||
|
||||
<br />
|
||||
|
||||
- **Create**: Spotify developers want to delight their customers with incredible features. They create new software to do that.
|
||||
- **Manage**: Spotify developers are proud of their work and treat their software and data like products. That requires maintaining all the software they own on an ongoing basis.
|
||||
@@ -73,7 +75,8 @@ Within today’s complex development environments, there are barriers both big a
|
||||
After talking with companies who have already adopted Backstage, we’ve seen a few common strategies for getting started. The different strategies are based on the size of your engineering org (which often also corresponds with how fast you’re growing).
|
||||
|
||||
|
||||
<br/>
|
||||
|
||||
<br />
|
||||
|
||||
### My org has ~200 engineers (and is growing fast)
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ In order to grow Backstage further, Spotify is increasing the support we provide
|
||||
|
||||
And while Spotify remains committed to maturing the Backstage platform — both as original creator and active maintainer — we also want to make room for the community to take greater ownership. Backstage may have started inside Spotify, but it belongs to all of you. So, we hope you join us in what’s next.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## What’s next: More support for adopters and contributors
|
||||
|
||||
+3
-3
@@ -13,7 +13,7 @@ So, you don’t just get an improved out-of-the-box experience for searching wha
|
||||
|
||||
With one query, your teams can find exactly what they’re looking for: anything and everything.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Search and explore
|
||||
|
||||
@@ -80,9 +80,9 @@ That's why we have put effort into making your search page experience composable
|
||||
|
||||
A good example of the level of customization the platform allows is how list items are displayed in search results. A search result component can be a list, this list can consist of different list items (search results returned from the search engine) — but these list items could look different depending on what the search result returns in terms of its fields.
|
||||
|
||||
Let’s say that for an entity returned from the software catalog maybe the most important information to show is the name, while a result returned from the TechDocs plugin should maybe show the text content as the most important information. This can be customized by creating <CustomResultListItem /> components (like TechDocsResultListItem or CatalogResultListItem or whatever list item component you want) and configuring them in the app.
|
||||
Let’s say that for an entity returned from the software catalog maybe the most important information to show is the name, while a result returned from the TechDocs plugin should maybe show the text content as the most important information. This can be customized by creating `<CustomResultListItem />` components (like `TechDocsResultListItem` or `CatalogResultListItem` or whatever list item component you want) and configuring them in the app.
|
||||
|
||||
If there is no need to customize your search result list items, the <DefaultResultListItem /> component is there for you to reuse.
|
||||
If there is no need to customize your search result list items, the `<DefaultResultListItem />` component is there for you to reuse.
|
||||
|
||||
## Getting started with Backstage Search
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ authorImageURL: https://avatars.githubusercontent.com/u/3645856?v=4
|
||||
|
||||
**TLDR**; At a high level, Backstage performs three main jobs: [Create, Manage, and Explore](https://backstage.io/blog/2021/05/20/adopting-backstage#three-jobs-create-manage-explore). Throughout the year, we’ve been focussed on improving the stability and scalability of these areas while enhancing the feature sets based upon requests from the community. Software Templates — which enable push-button deployments with all your standards and best practices built-in — is our first feature-complete release candidate to graduate to beta. Read on to learn how this release improves template customization and flexibility, as well as performance.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
Let’s rewind a little bit, around a year in fact. Backstage had been open sourced, and we released our first version of Software Templates and our Scaffolder plugin.
|
||||
|
||||
+12
-4
@@ -9,7 +9,7 @@ authorImageURL: https://avatars.githubusercontent.com/u/3496491?v=4
|
||||
|
||||
**TLDR:** Another beta has landed! We continue to focus on improving the stability and scalability of Backstage while enhancing its functionality. Thanks to focused efforts from the TechDocs core team and community, we're happy to say that TechDocs — [our docs-like-code solution](https://backstage.io/blog/2020/09/08/announcing-tech-docs) for all the software in your catalog — is now, after [Software Templates](https://backstage.io/blog/2021/07/26/software-templates-are-now-in-beta), the second core feature to graduate to beta.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
In addition to new features and improvements, we made numerous compatibility updates ahead of this feature release. You'll find support for a variety of CI systems, cloud storage solutions, and source control systems — so that TechDocs works for most orgs, right out of box. But there's much more to explore in this beta, thanks to contributions from the community.
|
||||
|
||||
@@ -21,7 +21,10 @@ When we set out to define what beta looked like, we combed through GitHub issues
|
||||
|
||||
TechDocs can be transformational once fully up and running (update your code and your docs with the same pull request!). But for first-time users and especially those unfamiliar with the MkDocs ecosystem upon which TechDocs is built, there are often many small, obtuse hurdles that can get in the way of success. Leading up to the beta release, we worked to surface and improve relevant errors and other details during the documentation generation process. Better still, all of this detail is now provided to users _in real-time_, as docs are generated and refreshed.
|
||||
|
||||
<p>🙌 Shout out to <a href="https://github.com/dhenneke">Dominik Henneke</a> for implementing the interactive experience.</p>
|
||||
<p>
|
||||
🙌 Shout out to <a href="https://github.com/dhenneke">Dominik Henneke</a> for
|
||||
implementing the interactive experience.
|
||||
</p>
|
||||
|
||||
## Custom homepages: Make TechDocs yours
|
||||
|
||||
@@ -29,7 +32,10 @@ TechDocs can be transformational once fully up and running (update your code and
|
||||
|
||||
We strive to make it so that you can mold Backstage into the shape that best fits your organization. With this beta release, just as you can with the Catalog entities and [Search](https://backstage.io/blog/2021/06/24/announcing-backstage-search-platform#composable-search-page-experiences), you can now customize and compose your own TechDocs homepage. Use it to level up the front page of your Backstage documentation by highlighting golden documentation at your company, or use the new and improved (and Catalog-inspired) experience. Read more about [how to customize the TechDocs homepage](https://backstage.io/docs/features/techdocs/how-to-guides#how-to-customize-the-techdocs-home-page).
|
||||
|
||||
<p>🙏 Thanks to <a href="https://github.com/kuangp">Phil Kuang</a> for the improved default TechDocs home experience.</p>
|
||||
<p>
|
||||
🙏 Thanks to <a href="https://github.com/kuangp">Phil Kuang</a> for the
|
||||
improved default TechDocs home experience.
|
||||
</p>
|
||||
|
||||
## Simpler YAML annotations: What's in a ref?
|
||||
|
||||
@@ -39,7 +45,9 @@ We often forget that in order to enable TechDocs on a Catalog entity, documentat
|
||||
|
||||
In the beta, we've simplified this annotation dramatically for documentation authors, aligning its value with TechDocs' docs-like-code philosophy itself. In the vast majority of cases, its value will simply be `dir:.` — which means this catalog entity contains documentation and the mkdocs.yml file describing this documentation lives in the current directory. We continue to support edge cases for [other techdocs-ref annotation values](https://backstage.io/docs/features/techdocs/how-to-guides#how-to-understand-techdocs-ref-annotation-values), as well.
|
||||
|
||||
<p>👏 Another round of applause for Dominik for driving this improvement through.</p>
|
||||
<p>
|
||||
👏 Another round of applause for Dominik for driving this improvement through.
|
||||
</p>
|
||||
|
||||
## Everything neat and tidy
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ We’re excited to celebrate an important milestone for the Backstage community:
|
||||
|
||||
Before digging into why we believe this is so important, we want to send a huge “thank you” to all the Backstage adopters and contributors who have helped grow the Backstage community. First, to the publicly listed adopters as your visible support for the project excites others to learn more about Backstage. Second, to those non-listed adopters, many of whom still engage in the community via issues, comments, or code contributions. Thank you!
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Why we care about public adopters
|
||||
|
||||
+17
-3
@@ -15,7 +15,7 @@ In 2021 we’ve seen the project and community grow in every dimension, reaching
|
||||
|
||||
Now let’s hear from the maintainers and look at the stats!
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## The community grew…and grew
|
||||
|
||||
@@ -48,11 +48,25 @@ Along with the growth in contributors, PRs, and issues, our active, thriving com
|
||||
|
||||
Watch the visualization below to see where in the world all those contributions came from this past year.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/O1xtDv_XDt4" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
<iframe
|
||||
width="780"
|
||||
height="440"
|
||||
src="https://www.youtube.com/embed/O1xtDv_XDt4"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
|
||||
### What does 9,000 contributions look like?
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/bCqhoK7it2g" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
<iframe
|
||||
width="780"
|
||||
height="440"
|
||||
src="https://www.youtube.com/embed/bCqhoK7it2g"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
|
||||
Can you spot your name in the video above?
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ _This blog post is co-authored by Emma Indal ([@emmaindal](https://github.com/em
|
||||
|
||||
_TLDR;_ We’re excited to announce the arrival of homepage templates for Backstage. It can be intimidating to build up your own instance of Backstage, so we decided to make your life a bit easier by giving you an out-of-the-box homepage to hit the ground running. This template can be found in our [Backstage Storybook](https://backstage.io/storybook/?path=/story/plugins-home-templates--default-template), as well as future templates that we build.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Why homepage templates?
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ authorImageURL: https://avatars.githubusercontent.com/u/8433119?v=4
|
||||
|
||||
_TLDR;_ The Spotify team recently announced [Backstage Upgrade Helper](https://backstage.github.io/upgrade-helper): a tool that helps adopters keep their Backstage application up-to-date. **Spoiler alert**: this is also a hidden and heartwarming tale about the beauty of open source innovation.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Upgrading Backstage was a common pain point
|
||||
|
||||
+9
-2
@@ -9,7 +9,7 @@ authorImageURL: https://avatars1.githubusercontent.com/u/1236238?s=460&v=4
|
||||
|
||||
**TLDR:** Backstage has turned two. Of course, this is software, so we expect things to move fast. But when you have a passionate, worldwide community building together, we’ve now seen firsthand just how fast that can be. We’re marking our second year as a community by becoming a CNCF incubating project, reaching 100 public adopters, releasing version 1.0 of the core app, and other very nice birthday gifts. Rather than a toddler finding their feet, Backstage today is beginning to look awfully grown-up for a two-year-old.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Out of the Sandbox and into Incubation
|
||||
|
||||
@@ -49,7 +49,14 @@ The Backstage community is truly global with adopters and contributors from almo
|
||||
|
||||
We asked a few contributors and maintainers to share their thoughts around this two-year milestone.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/-j-waaybcH0" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
<iframe
|
||||
width="780"
|
||||
height="440"
|
||||
src="https://www.youtube.com/embed/-j-waaybcH0"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
|
||||
Warms the heart, doesn’t it? Thanks again to all our contributors for making this possible. Seriously. We’re proud of what the community has accomplished and how we’ve accomplished it. All along, it’s your enthusiasm and warm/collaborative/positive vibes that have carried us and this project through.
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ authorImageURL: https://avatars.githubusercontent.com/u/6010860?v=4
|
||||
|
||||
_TL;DR:_ If you’ve been waiting for Backstage to come out of beta, we’re excited to announce that Backstage 1.0 is here!
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
It’s been two years since Spotify [open sourced Backstage](https://backstage.io/blog/2020/03/16/announcing-backstage) so companies of all shapes and sizes — and in every industry all over the world — could build highly extensible and customized developer portals to best suit their organization’s needs and culture. Now hundreds of adopters are using Backstage as the single pane of glass for their core development, managing millions of components and technical documentation, and helping hundreds of thousands of developers be more productive and happy.
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ _This blog post is co-authored by Eric Peterson ([@iamEAP](https://github.com/ia
|
||||
|
||||
_TL;DR:_ Introducing the TechDocs Addon Framework — a way for us all to contribute and share additional features, TechDocs Addons, on top of the base docs-like-code experience.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
[TechDocs](https://backstage.io/docs/features/techdocs/) is a centralized platform for publishing, viewing, and discovering technical documentation across an entire organization. It's a solid foundation! But TechDocs doesn't solve higher order documentation needs on its own such as: How do you create and reinforce a culture of documentation? How do you build trust in the quality of technical documentation?
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ We first released the Backstage Search Platform over a year ago. Backstage Searc
|
||||
|
||||
Backstage Search Platform makes it possible for you to search across your entire software ecosystem. With a Search platform that is customizable and extendable, you can identify your needs within your organization and set up search to solve these problems. Whether it is to search through the Software Catalog or technical documentation generated by the TechDocs plugin.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## So what is Backstage Search 1.0?
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ authorURL: https://github.com/Rugvip
|
||||
|
||||
As an [Incubating project](https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/) within the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/), Backstage was fortunate enough to take advantage of a sponsored security audit. The [Open Source Technology Improvement Fund (OSTIF)](https://ostif.org/) sponsored the audit as part of its ongoing efforts to secure the open source software ecosystem, and the audit itself was performed by [X41 D-Sec](https://x41-dsec.de/). Our goal with the audit was to evaluate and improve Backstage’s security posture, focusing on the core Backstage framework and plugins.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## Report Findings and Fixes
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ authorImageURL: https://avatars.githubusercontent.com/u/3496491?v=4
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## What is the plugin analytics API?
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ Backstage continues to grow in [popularity and maturity](https://roadie.io/blog/
|
||||
|
||||
[](https://www.edx.org/course/introduction-to-backstage-developer-portals-made-easy)
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
The course, [Introduction to Backstage: Developer Portals Made Easy (LFS142x)](https://www.edx.org/course/introduction-to-backstage-developer-portals-made-easy), starts discussing the benefits of adopting a Developer Portal. Then, it dives into what is Backstage, its main features (Catalog, Scaffolder, TechDocs), and how to map its capabilities to your organization. At last, it provides tips on how to connect with the community to ease up your adoption journey.
|
||||
|
||||
+9
-2
@@ -12,7 +12,7 @@ Our community is full of people from across the globe who bring incredible engag
|
||||
|
||||
But before anticipating too much, let’s share some stats of this amazing 2022.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## We grew … a lot!
|
||||
|
||||
@@ -40,7 +40,14 @@ All of these people driving the enormous growth and maturity of the project are
|
||||
|
||||
Wow… that’s a lot of activity. We’ve generated this animation showing all of your contributions to the Backstage repository in 2022, look at this project grow:
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/GoWBvHpH5Cg" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
<iframe
|
||||
width="780"
|
||||
height="440"
|
||||
src="https://www.youtube.com/embed/GoWBvHpH5Cg"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
|
||||
## But wait… there’s more
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ At the heart of [Backstage](https://backstage.io/) is the [Backstage Software Ca
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
A common use case is for an organization to want to surface ownership and metadata about repositories. Backstage provides a mechanism for discovering and transforming repository information into a standard data structure and persisting it into the Backstage [Catalog](https://backstage.io/docs/features/software-catalog/). This process is known as ingestion, where all data is transformed into a standard Backstage data structure known as an entity. Entities in the Catalog’s data store are accessible to the Backstage App via the REST API.
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ authorURL: https://github.com/leemills83
|
||||
|
||||
Okay, everyone. Time to move on from all the 2022 reflections, Top 10 lists, and Wrapped(s), and turn our gaze in the other direction — towards 2023. As the Backstage team moves into the new year, we find ourselves asking those perennial questions: How can we continue to grow and enhance the Backstage community? How can we improve the experience for those adopting Backstage? How can we give the best support to Backstage contributors?
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
Well, we don’t have all the answers, but we do have some. So we wanted to share more on three ongoing initiatives aimed at moving the needle forward for these three distinct, yet interrelated, questions.
|
||||
|
||||
+10
-3
@@ -11,7 +11,7 @@ For the past year, the Backstage maintainer team has been spending time to give
|
||||
|
||||
We’re happy to announce that the [v1.11](https://backstage.io/docs/releases/v1.11.0) release includes the public alpha of the [new Backstage backend system](https://backstage.io/docs/backend-system/)! The system has already been available to use for some time, as some of you have already found, but this alpha release marks the point where we are finally ready to encourage widespread adoption by plugin builders. We still don’t recommend that you use this new system in your production setups just yet, more on that later.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## History of the Backstage backend system
|
||||
|
||||
@@ -37,9 +37,16 @@ A few months later as the RFC settled, we resumed work and followed up with an i
|
||||
|
||||
We wrapped up this work just before KubeCon NA 2022, with the full system implemented. The state of the system at this point was presented in our talk on the topic, which you can see just below. Except for a few API tweaks, this is what the system still looks like today.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/ZXF7uxrEBVY" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
<iframe
|
||||
width="780"
|
||||
height="440"
|
||||
src="https://www.youtube.com/embed/ZXF7uxrEBVY"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
|
||||
<br/>
|
||||
<br />
|
||||
|
||||
The final stage was all about polish, which we picked up at the beginning of this year. By leaving a bit of space between the main implementation, or phase two, and the polish phase, phase three, it was much easier to properly scrutinize our past solutions. We forget a lot of the low level reasoning for changes, and it is easier to step back and reconsider parts of the system. For example, we found that our initial design of the `createServiceFactory` function was unnecessarily complex, and could be made much simpler for most usages. In addition to reviewing all the APIs, we also wrote more documentation to help users, ensured that the local development and testing experience was solid, and double checked that there was a smooth migration path from the old system.
|
||||
|
||||
+24
-4
@@ -9,7 +9,7 @@ authorImageURL: https://avatars.githubusercontent.com/u/3645856?v=4
|
||||
|
||||
**TL;DR** Spotify released Backstage into open source three years ago today. Since then, the community has grown by leaps and bounds to stretch across the globe (and the Discord server!). Now that Backstage is a threenager, the growing pains are real. So, on this birthday, we want to cover our collective efforts to make it easier to adopt and contribute to Backstage.
|
||||
|
||||
<!--truncate-->
|
||||
{/* truncate */}
|
||||
|
||||
## They grow up so fast, don’t they?
|
||||
|
||||
@@ -33,9 +33,29 @@ But, without a doubt, the best thing about the Backstage project is the people i
|
||||
|
||||
Don’t take our word for it! Take a look at this birthday video we put together with a few community members.
|
||||
|
||||
<div style={{ position: 'relative', overflow: 'hidden', width: '100%', paddingTop: '56.25%'}}>
|
||||
<iframe style={{ position: 'absolute', top: 0, left: 0, right: 0, bottom: 0, width: '100%', height: '100%' }} src="https://www.youtube.com/embed/rllOa_MfEWw" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen>
|
||||
</iframe>
|
||||
<div
|
||||
style={{
|
||||
position: 'relative',
|
||||
overflow: 'hidden',
|
||||
width: '100%',
|
||||
paddingTop: '56.25%',
|
||||
}}
|
||||
>
|
||||
<iframe
|
||||
style={{
|
||||
position: 'absolute',
|
||||
top: 0,
|
||||
left: 0,
|
||||
right: 0,
|
||||
bottom: 0,
|
||||
width: '100%',
|
||||
height: '100%',
|
||||
}}
|
||||
src="https://www.youtube.com/embed/rllOa_MfEWw"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
</div>
|
||||
|
||||
## The growing pains are real
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: 'ICYMI: KubeCon EU 2023'
|
||||
author: Bailey Brooks, Spotify
|
||||
authorURL: http://github.com/bailey
|
||||
authorImageURL: https://pbs.twimg.com/profile_images/1477424303192694785/qCfN6XWW_400x400.jpg
|
||||
---
|
||||
|
||||
|
||||
|
||||
We had a blast talking all things Backstage at KubeCon EU 2023 in Amsterdam last week. In case you missed it, here’s a quick recap:
|
||||
|
||||
{/* truncate */}
|
||||
|
||||
## Backstage Project Meeting
|
||||
|
||||
|
||||
|
||||
On Tuesday the Backstage maintainers hosted a jam-packed project meeting. The community welcomed many teams and individuals that were early in their Backstage journey, either actively adopting, preparing for the POC phase, or learning about the capabilities of Backstage. Many of the newcomers were eager to learn about how Backstage could help streamline their development workflows and improve developer productivity. During the project meeting, the maintainers covered a “day in the life” of a core maintainer, walked through spinning up a new instance of Backstage in a live demo, and opened it up to questions from the community. It’s super exciting to see so much growing interest in Backstage and all of the ways adopters are adapting it to their needs.
|
||||
|
||||
## State of Backstage in 2023
|
||||
|
||||
|
||||
|
||||
Core maintainers [Ben Lambert](https://github.com/benjdlambert) and [Patrik Oldsberg](https://github.com/Rugvip) took center stage on Wednesday for the Backstage Maintainer Track: State of Backstage in 2023 talk. Backstage has officially hit over 1,000 adopters and 1,000 contributors – so it’s apt timing to modernize the governance model for the project. Taking pointers from the [CNCF Contributor Ladder Governance Template](https://contribute.cncf.io/maintainers/templates/), a new [Backstage Governance Model](https://github.com/backstage/backstage/blob/master/GOVERNANCE.md) is now in effect! Patrik walked us through the new ladder model which introduces a number of changes, one being the addition of [project area maintainers](https://github.com/backstage/backstage/blob/master/GOVERNANCE.md#project-area-maintainer). This role lets members of the community take increased ownership over a specific area of interest, like Catalog, Discoverability, TechDocs, Helm Charts, and Kubernetes. New project areas that will be added include Permissions and Software Templates. New project areas can be proposed by nominating a project area maintainer for the area. The new model also adds an organization member role for contributors who want to take a more active role in the Backstage community. You can open an issue to become an organization member [here](https://github.com/backstage/community/issues/new/choose).
|
||||
|
||||
|
||||
|
||||
Ben and Patrik also covered new capabilities for Software Templates and framework updates. Lots of exciting new features are planned for Software Templates including a new UI, async validation for CustomFieldExtensions, and embedded workflows. Lastly, the maintainers also announced a new focus on declarative integration – permitting plugin installation without TypeScript. Development is still early, but we can’t wait to see this in action!
|
||||
|
||||
## Other KubeCon excitement!
|
||||
|
||||
Throughout the week, we also heard success stories of adopters, like AppsFlyer’s talk, “How We Migrated Over 1000 Services to Backstage Using GitOps and Survived to Talk About It!” AppsFlyer has over 1,000 services and processes over 200 billion events per day – so migrating to Backstage as their service catalog platform was no small feat. As part of their migration, they also integrated GitOps and Terraform into their Backstage instance. Many attendees found interest in these case studies where you could see the adoption and POC process directly from other adopters. It was exciting to see firsthand how teams can extend Backstage to fit their needs on the fly.
|
||||
|
||||
We were thrilled to see so much excitement and interest brewing around Backstage this year! If you missed it, you can catch up as soon as more talks are added to the [CNCF YouTube channel](https://www.youtube.com/@cncf/featured). We can’t wait to catch up with you all again soon at KubeCon North America in Chicago.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 594 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 13 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 460 KiB |
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: 'ChatGPT Plugin'
|
||||
author: Enfuse
|
||||
authorUrl: https://enfuse.io/
|
||||
category: Development
|
||||
description: Experiment with the OpenAI playground to help you develop more efficiently
|
||||
documentation: https://github.com/enfuse/backstage-chatgpt-plugin/blob/main/README.md
|
||||
iconUrl: /img/enfuse.png
|
||||
npmPackageName: '@enfuse/chatgpt-plugin-frontend'
|
||||
addedDate: '2023-04-21'
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: dbt Docs
|
||||
author: IIBenII
|
||||
authorUrl: https://github.com/IIBenII
|
||||
category: Discovery
|
||||
description: View dbt models and tests documentation.
|
||||
documentation: https://github.com/IIBenII/backstage-plugin-dbt
|
||||
npmPackageName: '@iiben_orgii/backstage-plugin-dbt'
|
||||
tags:
|
||||
- dbt
|
||||
- doc
|
||||
addedDate: '2023-04-27'
|
||||
@@ -68,6 +68,12 @@ module.exports = {
|
||||
},
|
||||
],
|
||||
],
|
||||
markdown: {
|
||||
preprocessor({ filePath, fileContent }) {
|
||||
// Replace all HTML comments with emtpy strings as these are not supported by MDXv2.
|
||||
return fileContent.replace(/<!--.*?-->/gs, '');
|
||||
},
|
||||
},
|
||||
webpack: {
|
||||
jsLoader: isServer => ({
|
||||
loader: require.resolve('swc-loader'),
|
||||
|
||||
@@ -17,21 +17,20 @@
|
||||
"docusaurus": "docusaurus"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@docusaurus/module-type-aliases": "2.4.0",
|
||||
"@docusaurus/module-type-aliases": "0.0.0-5566",
|
||||
"@spotify/prettier-config": "^14.0.0",
|
||||
"@tsconfig/docusaurus": "^1.0.6",
|
||||
"@types/webpack-env": "^1.18.0",
|
||||
"js-yaml": "^4.1.0",
|
||||
"prettier": "^2.6.2",
|
||||
"replace": "^1.2.2",
|
||||
"typescript": "^4.9.4",
|
||||
"yaml-loader": "^0.8.0"
|
||||
},
|
||||
"prettier": "@spotify/prettier-config",
|
||||
"dependencies": {
|
||||
"@docusaurus/core": "2.4.0",
|
||||
"@docusaurus/plugin-client-redirects": "^2.3.1",
|
||||
"@docusaurus/preset-classic": "2.4.0",
|
||||
"@docusaurus/core": "0.0.0-5566",
|
||||
"@docusaurus/plugin-client-redirects": "0.0.0-5566",
|
||||
"@docusaurus/preset-classic": "0.0.0-5566",
|
||||
"@swc/core": "^1.3.46",
|
||||
"clsx": "^1.1.1",
|
||||
"docusaurus-plugin-sass": "^0.2.3",
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user