Merge remote-tracking branch 'origin/master'
This commit is contained in:
headphonejames
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
Fixed a bug that could prevent auth from working when using the `guest` or `custom` auth providers.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': patch
|
||||
---
|
||||
|
||||
Rename output parameter `mergeRequestURL` of `publish:gitlab:merge-request` action to `mergeRequestUrl`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-common': patch
|
||||
---
|
||||
|
||||
Added permissions for authorizing parameters and steps
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': patch
|
||||
---
|
||||
|
||||
Bumped create-app version.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-api-docs': patch
|
||||
---
|
||||
|
||||
Corrected styling of nested objects in AsyncAPI to avoid inappropriate uppercase text transformation of nested objects.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
'@backstage/plugin-scaffolder-backend': patch
|
||||
'@backstage/plugin-scaffolder-node': patch
|
||||
'@backstage/plugin-scaffolder-react': patch
|
||||
---
|
||||
|
||||
Added a possibility to cancel the running task (executing of a scaffolder template)
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-org': patch
|
||||
---
|
||||
|
||||
Allow the title of the group profile card to use the title of the entity, if it is set.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-kubernetes-backend': minor
|
||||
---
|
||||
|
||||
**BREAKING**: `KubernetesBuilder.create` now requires a `permissions` field of type `PermissionEvaluator`. The kubernetes `/proxy` endpoint now requires two tokens: the `Backstage-Kubernetes-Authorization` header should contain a bearer token for the target cluster, and the `Authorization` header should contain a backstage identity token. The kubernetes `/proxy` endpoint now requires a `Backstage-Kubernetes-Cluster` header replacing the previously required `X-Kubernetes-Cluster` header.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Support importing `.md` files in build loader
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
---
|
||||
|
||||
Allow use of `{ exists: true }` value inside filters to filter entities that has that key.
|
||||
|
||||
this example will filter all entities that has the annotation `someAnnotation` set to any value.
|
||||
|
||||
```yaml
|
||||
ui:options:
|
||||
catalogFilter:
|
||||
kind: Group
|
||||
metadata.annotations.someAnnotation: { exists: true }
|
||||
```
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/plugin-entity-feedback': minor
|
||||
'@backstage/plugin-entity-feedback-backend': patch
|
||||
'@backstage/plugin-entity-feedback-common': patch
|
||||
---
|
||||
|
||||
Added an endpoint to fetch anonymous aggregated results from an entity
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-gitlab': minor
|
||||
---
|
||||
|
||||
**BREAKING**: The configuration of the `GitlabDiscoveryEntityProvider` has changed as follows:
|
||||
|
||||
- The configuration key `branch` is now used to define the branch from which the catalog-info should be discovered.
|
||||
- The old configuration key `branch` is now called `fallbackBranch`. This value specifies which branch should be used
|
||||
if no default branch is defined on the project itself.
|
||||
|
||||
To migrate to the new configuration value, rename `branch` to `fallbackBranch`
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-search-backend': minor
|
||||
---
|
||||
|
||||
Exports search plugin that can be used with the new backend system. For documentation on how to migrate, check out the [how to migrate to the new backend system guide](../docs/features/search/how-to-guides.md#how-to-migrate-to-use-search-together-with-the-new-backend-system).
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': patch
|
||||
---
|
||||
|
||||
Add `permissionApi` as dependency of the scaffolder-backend plugin
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-kubernetes-backend': patch
|
||||
---
|
||||
|
||||
Fixes bug whereby backstage crashes when bad credentials are provided to the kubernetes plugin.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': minor
|
||||
---
|
||||
|
||||
Added `fetch:plain:file` action to fetch a single file, this action is also added to the list of built-in actions.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-search-backend-module-elasticsearch': minor
|
||||
'@backstage/plugin-search-backend-module-pg': patch
|
||||
---
|
||||
|
||||
Search backend modules migrated to the new backend system. For documentation on how to migrate, check out the [how to migrate to the new backend system guide](../docs/features/search/how-to-guides.md#how-to-migrate-to-use-search-together-with-the-new-backend-system).
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-common': patch
|
||||
---
|
||||
|
||||
Export `typeguard` for `isTemplateEntityV1beta3`
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-gitlab': patch
|
||||
---
|
||||
|
||||
The gitlab org data integration now makes use of the GraphQL API to determine
|
||||
the relationships between imported User and Group entities, effectively making
|
||||
this integration usable without an administrator account's Personal Access
|
||||
Token.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog': minor
|
||||
---
|
||||
|
||||
Added a new EntitySwitch isResourceType to allow different views depending on Resource type
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-auth-backend': patch
|
||||
---
|
||||
|
||||
Enforce the secret visibility of certificates and client secrets in the auth backend. Also, document all known options for each auth plugin.
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-msgraph': patch
|
||||
'@backstage/plugin-catalog-backend-module-openapi': patch
|
||||
'@backstage/plugin-catalog-backend-module-ldap': patch
|
||||
'@backstage/plugin-scaffolder-backend': patch
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
---
|
||||
|
||||
Fix deprecated types.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-react': patch
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
---
|
||||
|
||||
`scaffolder/next`: Bump `@rjsf/*` deps to 5.3.1
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-tech-insights': patch
|
||||
---
|
||||
|
||||
The `Check` type now optionally includes the `failureMetadata` and `successMetadata` as returned by the `runChecks` call.
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
'@backstage/app-defaults': minor
|
||||
'@backstage/core-app-api': minor
|
||||
'@backstage/plugin-auth-backend': patch
|
||||
'@backstage/test-utils': minor
|
||||
---
|
||||
|
||||
Introduce a new global config parameter, `auth.enableExperimentalRedirectFlow`. When enabled, auth will happen with an in-window redirect flow rather than through a popup window.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-search-react': patch
|
||||
'@backstage/plugin-techdocs': patch
|
||||
---
|
||||
|
||||
Fixes a UI bug in search result item which rendered the item text with incorrect font size and color
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Fixed backend start command on Windows by removing the use of platform dependent path joins.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-gitlab': minor
|
||||
---
|
||||
|
||||
Add Gitlab Scaffolder Plugin
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder': minor
|
||||
---
|
||||
|
||||
scaffolder/next: removing the `routeRefs` and exporting the originals on `scaffolderPlugin.routes.x` instead
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-permission-node': patch
|
||||
---
|
||||
|
||||
Added createConditionAuthorizer utility function, which takes some permission conditions and returns a function that returns a definitive authorization result given a decision and a resource.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': minor
|
||||
---
|
||||
|
||||
Added the possibility to authorize parameters and steps of a template
|
||||
|
||||
The scaffolder plugin is now integrated with the permission framework.
|
||||
It is possible to toggle parameters or actions within templates by marking each section with specific `tags`, inside a `backstage:permissions` property under each parameter or action. Each parameter or action can then be permissioned by using a conditional decision containing the `scaffolderTemplateRules.hasTag` rule.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
---
|
||||
|
||||
Add full text search support to the `by-query` endpoint.
|
||||
@@ -0,0 +1,262 @@
|
||||
{
|
||||
"mode": "pre",
|
||||
"tag": "next",
|
||||
"initialVersions": {
|
||||
"example-app": "0.2.81",
|
||||
"@backstage/app-defaults": "1.2.1",
|
||||
"example-backend": "0.2.81",
|
||||
"@backstage/backend-app-api": "0.4.1",
|
||||
"@backstage/backend-common": "0.18.3",
|
||||
"@backstage/backend-defaults": "0.1.8",
|
||||
"@backstage/backend-dev-utils": "0.1.1",
|
||||
"example-backend-next": "0.0.9",
|
||||
"@backstage/backend-plugin-api": "0.5.0",
|
||||
"@backstage/backend-tasks": "0.5.0",
|
||||
"@backstage/backend-test-utils": "0.1.35",
|
||||
"@backstage/catalog-client": "1.4.0",
|
||||
"@backstage/catalog-model": "1.2.1",
|
||||
"@backstage/cli": "0.22.4",
|
||||
"@backstage/cli-common": "0.1.12",
|
||||
"@backstage/codemods": "0.1.44",
|
||||
"@backstage/config": "1.0.7",
|
||||
"@backstage/config-loader": "1.1.9",
|
||||
"@backstage/core-app-api": "1.6.0",
|
||||
"@backstage/core-components": "0.12.5",
|
||||
"@backstage/core-plugin-api": "1.5.0",
|
||||
"@backstage/create-app": "0.4.38",
|
||||
"@backstage/dev-utils": "1.0.13",
|
||||
"e2e-test": "0.2.1",
|
||||
"@backstage/errors": "1.1.5",
|
||||
"@backstage/eslint-plugin": "0.1.2",
|
||||
"@backstage/integration": "1.4.3",
|
||||
"@backstage/integration-aws-node": "0.1.2",
|
||||
"@backstage/integration-react": "1.1.11",
|
||||
"@backstage/release-manifests": "0.0.9",
|
||||
"@backstage/repo-tools": "0.1.3",
|
||||
"@techdocs/cli": "1.4.0",
|
||||
"techdocs-cli-embedded-app": "0.2.80",
|
||||
"@backstage/test-utils": "1.2.6",
|
||||
"@backstage/theme": "0.2.18",
|
||||
"@backstage/types": "1.0.2",
|
||||
"@backstage/version-bridge": "1.0.3",
|
||||
"@backstage/plugin-adr": "0.4.1",
|
||||
"@backstage/plugin-adr-backend": "0.3.1",
|
||||
"@backstage/plugin-adr-common": "0.2.7",
|
||||
"@backstage/plugin-airbrake": "0.3.16",
|
||||
"@backstage/plugin-airbrake-backend": "0.2.16",
|
||||
"@backstage/plugin-allure": "0.1.32",
|
||||
"@backstage/plugin-analytics-module-ga": "0.1.27",
|
||||
"@backstage/plugin-apache-airflow": "0.2.9",
|
||||
"@backstage/plugin-api-docs": "0.9.1",
|
||||
"@backstage/plugin-api-docs-module-protoc-gen-doc": "0.1.1",
|
||||
"@backstage/plugin-apollo-explorer": "0.1.9",
|
||||
"@backstage/plugin-app-backend": "0.3.43",
|
||||
"@backstage/plugin-auth-backend": "0.18.1",
|
||||
"@backstage/plugin-auth-node": "0.2.12",
|
||||
"@backstage/plugin-azure-devops": "0.2.7",
|
||||
"@backstage/plugin-azure-devops-backend": "0.3.22",
|
||||
"@backstage/plugin-azure-devops-common": "0.3.0",
|
||||
"@backstage/plugin-azure-sites": "0.1.5",
|
||||
"@backstage/plugin-azure-sites-backend": "0.1.5",
|
||||
"@backstage/plugin-azure-sites-common": "0.1.0",
|
||||
"@backstage/plugin-badges": "0.2.40",
|
||||
"@backstage/plugin-badges-backend": "0.1.37",
|
||||
"@backstage/plugin-bazaar": "0.2.6",
|
||||
"@backstage/plugin-bazaar-backend": "0.2.6",
|
||||
"@backstage/plugin-bitbucket-cloud-common": "0.2.4",
|
||||
"@backstage/plugin-bitrise": "0.1.43",
|
||||
"@backstage/plugin-catalog": "1.9.0",
|
||||
"@backstage/plugin-catalog-backend": "1.8.0",
|
||||
"@backstage/plugin-catalog-backend-module-aws": "0.1.17",
|
||||
"@backstage/plugin-catalog-backend-module-azure": "0.1.14",
|
||||
"@backstage/plugin-catalog-backend-module-bitbucket": "0.2.10",
|
||||
"@backstage/plugin-catalog-backend-module-bitbucket-cloud": "0.1.10",
|
||||
"@backstage/plugin-catalog-backend-module-bitbucket-server": "0.1.8",
|
||||
"@backstage/plugin-catalog-backend-module-gerrit": "0.1.11",
|
||||
"@backstage/plugin-catalog-backend-module-github": "0.2.6",
|
||||
"@backstage/plugin-catalog-backend-module-gitlab": "0.1.14",
|
||||
"@backstage/plugin-catalog-backend-module-incremental-ingestion": "0.3.0",
|
||||
"@backstage/plugin-catalog-backend-module-ldap": "0.5.10",
|
||||
"@backstage/plugin-catalog-backend-module-msgraph": "0.5.2",
|
||||
"@backstage/plugin-catalog-backend-module-openapi": "0.1.9",
|
||||
"@backstage/plugin-catalog-backend-module-puppetdb": "0.1.0",
|
||||
"@backstage/plugin-catalog-common": "1.0.12",
|
||||
"@internal/plugin-catalog-customized": "0.0.8",
|
||||
"@backstage/plugin-catalog-graph": "0.2.28",
|
||||
"@backstage/plugin-catalog-graphql": "0.3.19",
|
||||
"@backstage/plugin-catalog-import": "0.9.6",
|
||||
"@backstage/plugin-catalog-node": "1.3.4",
|
||||
"@backstage/plugin-catalog-react": "1.4.0",
|
||||
"@backstage/plugin-cicd-statistics": "0.1.18",
|
||||
"@backstage/plugin-cicd-statistics-module-gitlab": "0.1.12",
|
||||
"@backstage/plugin-circleci": "0.3.16",
|
||||
"@backstage/plugin-cloudbuild": "0.3.16",
|
||||
"@backstage/plugin-code-climate": "0.1.16",
|
||||
"@backstage/plugin-code-coverage": "0.2.9",
|
||||
"@backstage/plugin-code-coverage-backend": "0.2.9",
|
||||
"@backstage/plugin-codescene": "0.1.11",
|
||||
"@backstage/plugin-config-schema": "0.1.39",
|
||||
"@backstage/plugin-cost-insights": "0.12.5",
|
||||
"@backstage/plugin-cost-insights-common": "0.1.1",
|
||||
"@backstage/plugin-dynatrace": "3.0.0",
|
||||
"@backstage/plugin-entity-feedback": "0.1.1",
|
||||
"@backstage/plugin-entity-feedback-backend": "0.1.1",
|
||||
"@backstage/plugin-entity-feedback-common": "0.1.0",
|
||||
"@backstage/plugin-entity-validation": "0.1.1",
|
||||
"@backstage/plugin-events-backend": "0.2.4",
|
||||
"@backstage/plugin-events-backend-module-aws-sqs": "0.1.5",
|
||||
"@backstage/plugin-events-backend-module-azure": "0.1.5",
|
||||
"@backstage/plugin-events-backend-module-bitbucket-cloud": "0.1.5",
|
||||
"@backstage/plugin-events-backend-module-gerrit": "0.1.5",
|
||||
"@backstage/plugin-events-backend-module-github": "0.1.5",
|
||||
"@backstage/plugin-events-backend-module-gitlab": "0.1.5",
|
||||
"@backstage/plugin-events-backend-test-utils": "0.1.5",
|
||||
"@backstage/plugin-events-node": "0.2.4",
|
||||
"@internal/plugin-todo-list": "1.0.11",
|
||||
"@internal/plugin-todo-list-backend": "1.0.11",
|
||||
"@internal/plugin-todo-list-common": "1.0.9",
|
||||
"@backstage/plugin-explore": "0.4.1",
|
||||
"@backstage/plugin-explore-backend": "0.0.5",
|
||||
"@backstage/plugin-explore-common": "0.0.1",
|
||||
"@backstage/plugin-explore-react": "0.0.27",
|
||||
"@backstage/plugin-firehydrant": "0.2.0",
|
||||
"@backstage/plugin-fossa": "0.2.48",
|
||||
"@backstage/plugin-gcalendar": "0.3.12",
|
||||
"@backstage/plugin-gcp-projects": "0.3.35",
|
||||
"@backstage/plugin-git-release-manager": "0.3.29",
|
||||
"@backstage/plugin-github-actions": "0.5.16",
|
||||
"@backstage/plugin-github-deployments": "0.1.47",
|
||||
"@backstage/plugin-github-issues": "0.2.5",
|
||||
"@backstage/plugin-github-pull-requests-board": "0.1.10",
|
||||
"@backstage/plugin-gitops-profiles": "0.3.34",
|
||||
"@backstage/plugin-gocd": "0.1.22",
|
||||
"@backstage/plugin-graphiql": "0.2.48",
|
||||
"@backstage/plugin-graphql-backend": "0.1.33",
|
||||
"@backstage/plugin-graphql-voyager": "0.1.1",
|
||||
"@backstage/plugin-home": "0.4.32",
|
||||
"@backstage/plugin-ilert": "0.2.5",
|
||||
"@backstage/plugin-jenkins": "0.7.15",
|
||||
"@backstage/plugin-jenkins-backend": "0.1.33",
|
||||
"@backstage/plugin-jenkins-common": "0.1.14",
|
||||
"@backstage/plugin-kafka": "0.3.16",
|
||||
"@backstage/plugin-kafka-backend": "0.2.36",
|
||||
"@backstage/plugin-kubernetes": "0.7.9",
|
||||
"@backstage/plugin-kubernetes-backend": "0.9.4",
|
||||
"@backstage/plugin-kubernetes-common": "0.6.1",
|
||||
"@backstage/plugin-lighthouse": "0.4.1",
|
||||
"@backstage/plugin-lighthouse-backend": "0.1.1",
|
||||
"@backstage/plugin-lighthouse-common": "0.1.1",
|
||||
"@backstage/plugin-linguist": "0.1.1",
|
||||
"@backstage/plugin-linguist-backend": "0.2.0",
|
||||
"@backstage/plugin-linguist-common": "0.1.0",
|
||||
"@backstage/plugin-microsoft-calendar": "0.1.1",
|
||||
"@backstage/plugin-newrelic": "0.3.34",
|
||||
"@backstage/plugin-newrelic-dashboard": "0.2.9",
|
||||
"@backstage/plugin-octopus-deploy": "0.1.0",
|
||||
"@backstage/plugin-org": "0.6.6",
|
||||
"@backstage/plugin-org-react": "0.1.5",
|
||||
"@backstage/plugin-pagerduty": "0.5.9",
|
||||
"@backstage/plugin-periskop": "0.1.14",
|
||||
"@backstage/plugin-periskop-backend": "0.1.14",
|
||||
"@backstage/plugin-permission-backend": "0.5.18",
|
||||
"@backstage/plugin-permission-common": "0.7.4",
|
||||
"@backstage/plugin-permission-node": "0.7.6",
|
||||
"@backstage/plugin-permission-react": "0.4.11",
|
||||
"@backstage/plugin-playlist": "0.1.7",
|
||||
"@backstage/plugin-playlist-backend": "0.2.6",
|
||||
"@backstage/plugin-playlist-common": "0.1.5",
|
||||
"@backstage/plugin-proxy-backend": "0.2.37",
|
||||
"@backstage/plugin-rollbar": "0.4.16",
|
||||
"@backstage/plugin-rollbar-backend": "0.1.40",
|
||||
"@backstage/plugin-scaffolder": "1.12.0",
|
||||
"@backstage/plugin-scaffolder-backend": "1.12.0",
|
||||
"@backstage/plugin-scaffolder-backend-module-cookiecutter": "0.2.18",
|
||||
"@backstage/plugin-scaffolder-backend-module-rails": "0.4.11",
|
||||
"@backstage/plugin-scaffolder-backend-module-sentry": "0.1.3",
|
||||
"@backstage/plugin-scaffolder-backend-module-yeoman": "0.2.16",
|
||||
"@backstage/plugin-scaffolder-common": "1.2.6",
|
||||
"@backstage/plugin-scaffolder-node": "0.1.1",
|
||||
"@backstage/plugin-scaffolder-react": "1.2.0",
|
||||
"@backstage/plugin-search": "1.1.1",
|
||||
"@backstage/plugin-search-backend": "1.2.4",
|
||||
"@backstage/plugin-search-backend-module-elasticsearch": "1.1.4",
|
||||
"@backstage/plugin-search-backend-module-pg": "0.5.4",
|
||||
"@backstage/plugin-search-backend-node": "1.1.4",
|
||||
"@backstage/plugin-search-common": "1.2.2",
|
||||
"@backstage/plugin-search-react": "1.5.1",
|
||||
"@backstage/plugin-sentry": "0.5.1",
|
||||
"@backstage/plugin-shortcuts": "0.3.8",
|
||||
"@backstage/plugin-sonarqube": "0.6.5",
|
||||
"@backstage/plugin-sonarqube-backend": "0.1.8",
|
||||
"@backstage/plugin-sonarqube-react": "0.1.4",
|
||||
"@backstage/plugin-splunk-on-call": "0.4.5",
|
||||
"@backstage/plugin-stack-overflow": "0.1.12",
|
||||
"@backstage/plugin-stack-overflow-backend": "0.1.12",
|
||||
"@backstage/plugin-stackstorm": "0.1.0",
|
||||
"@backstage/plugin-tech-insights": "0.3.8",
|
||||
"@backstage/plugin-tech-insights-backend": "0.5.9",
|
||||
"@backstage/plugin-tech-insights-backend-module-jsonfc": "0.1.27",
|
||||
"@backstage/plugin-tech-insights-common": "0.2.10",
|
||||
"@backstage/plugin-tech-insights-node": "0.4.1",
|
||||
"@backstage/plugin-tech-radar": "0.6.2",
|
||||
"@backstage/plugin-techdocs": "1.6.0",
|
||||
"@backstage/plugin-techdocs-addons-test-utils": "1.0.11",
|
||||
"@backstage/plugin-techdocs-backend": "1.6.0",
|
||||
"@backstage/plugin-techdocs-module-addons-contrib": "1.0.11",
|
||||
"@backstage/plugin-techdocs-node": "1.6.0",
|
||||
"@backstage/plugin-techdocs-react": "1.1.4",
|
||||
"@backstage/plugin-todo": "0.2.18",
|
||||
"@backstage/plugin-todo-backend": "0.1.40",
|
||||
"@backstage/plugin-user-settings": "0.7.1",
|
||||
"@backstage/plugin-user-settings-backend": "0.1.7",
|
||||
"@backstage/plugin-vault": "0.1.10",
|
||||
"@backstage/plugin-vault-backend": "0.2.10",
|
||||
"@backstage/plugin-xcmetrics": "0.2.36",
|
||||
"@backstage/plugin-scaffolder-backend-module-gitlab": "0.0.0"
|
||||
},
|
||||
"changesets": [
|
||||
"bright-pumpkins-bake",
|
||||
"create-app-1679405836",
|
||||
"curly-boats-trade",
|
||||
"curly-jobs-kneel",
|
||||
"eleven-bats-tease",
|
||||
"fair-roses-stare",
|
||||
"fast-snakes-buy",
|
||||
"fresh-schools-fly",
|
||||
"fuzzy-actors-turn",
|
||||
"heavy-colts-wash",
|
||||
"hungry-lies-cry",
|
||||
"hungry-monkeys-reply",
|
||||
"khaki-cars-drum",
|
||||
"khaki-doors-compare",
|
||||
"khaki-guests-turn",
|
||||
"lazy-apples-destroy",
|
||||
"lazy-monkeys-worry",
|
||||
"long-gorillas-remain",
|
||||
"many-eggs-press",
|
||||
"mighty-lamps-cross",
|
||||
"nasty-nails-appear",
|
||||
"neat-donkeys-work",
|
||||
"old-cougars-sit",
|
||||
"orange-rabbits-jam",
|
||||
"rare-seals-decide",
|
||||
"renovate-a9116b7",
|
||||
"renovate-c574b04",
|
||||
"rotten-carrots-cheer",
|
||||
"seven-gifts-fetch",
|
||||
"short-panthers-float",
|
||||
"soft-roses-cover",
|
||||
"sour-dragons-cheat",
|
||||
"strong-crews-repeat",
|
||||
"swift-meals-live",
|
||||
"ten-hounds-bathe",
|
||||
"ten-mayflies-beam",
|
||||
"thick-forks-prove",
|
||||
"thin-spoons-prove",
|
||||
"thirty-crabs-tell",
|
||||
"twelve-parrots-camp",
|
||||
"weak-turtles-arrive",
|
||||
"wise-garlics-camp",
|
||||
"witty-berries-love"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
'@backstage/plugin-analytics-module-ga': patch
|
||||
'@backstage/plugin-apollo-explorer': patch
|
||||
'@backstage/plugin-adr-backend': patch
|
||||
'@backstage/plugin-dynatrace': patch
|
||||
'@backstage/plugin-airbrake': patch
|
||||
'@backstage/plugin-circleci': patch
|
||||
'@backstage/plugin-adr': patch
|
||||
---
|
||||
|
||||
chore: Improve API Reference documentation
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-techdocs-react': patch
|
||||
---
|
||||
|
||||
Fix a bug that caused the header to not render when generating a document for the first time
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
'@backstage/plugin-entity-validation': patch
|
||||
'@backstage/integration-react': patch
|
||||
'@backstage/plugin-apollo-explorer': patch
|
||||
'@backstage/plugin-github-issues': patch
|
||||
'@backstage/plugin-stackstorm': patch
|
||||
'@backstage/plugin-codescene': patch
|
||||
'@backstage/plugin-org-react': patch
|
||||
'@backstage/plugin-linguist': patch
|
||||
'@backstage/plugin-playlist': patch
|
||||
'@backstage/plugin-vault': patch
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Updated dependency `@material-ui/lab` to `4.0.0-alpha.61`.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-react': patch
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
---
|
||||
|
||||
Updated dependency `@rjsf/validator-ajv8` to `5.3.0`.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-graphql': patch
|
||||
'@backstage/plugin-graphql-backend': patch
|
||||
---
|
||||
|
||||
Updated dependency `@apollo/server` to `^4.0.0`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-app-api': patch
|
||||
---
|
||||
|
||||
Register unhandled rejection and uncaught exception handlers to avoid backend crashes.
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
'@backstage/plugin-techdocs-module-addons-contrib': patch
|
||||
'@backstage/plugin-github-pull-requests-board': patch
|
||||
'@backstage/plugin-techdocs-addons-test-utils': patch
|
||||
'@backstage/plugin-analytics-module-ga': patch
|
||||
'@backstage/plugin-git-release-manager': patch
|
||||
'@backstage/plugin-github-deployments': patch
|
||||
'@backstage/plugin-newrelic-dashboard': patch
|
||||
'@backstage/core-components': patch
|
||||
'@backstage/plugin-scaffolder-react': patch
|
||||
'@backstage/plugin-cicd-statistics': patch
|
||||
'@backstage/plugin-entity-feedback': patch
|
||||
'@backstage/plugin-gitops-profiles': patch
|
||||
'@backstage/plugin-graphql-voyager': patch
|
||||
'@backstage/plugin-apache-airflow': patch
|
||||
'@backstage/plugin-catalog-import': patch
|
||||
'@backstage/plugin-github-actions': patch
|
||||
'@backstage/plugin-octopus-deploy': patch
|
||||
'@backstage/plugin-splunk-on-call': patch
|
||||
'@backstage/plugin-techdocs-react': patch
|
||||
'@backstage/plugin-catalog-graph': patch
|
||||
'@backstage/plugin-catalog-react': patch
|
||||
'@backstage/plugin-code-coverage': patch
|
||||
'@backstage/plugin-config-schema': patch
|
||||
'@backstage/plugin-cost-insights': patch
|
||||
'@backstage/plugin-tech-insights': patch
|
||||
'@backstage/plugin-user-settings': patch
|
||||
'@backstage/plugin-azure-devops': patch
|
||||
'@backstage/plugin-code-climate': patch
|
||||
'@backstage/plugin-gcp-projects': patch
|
||||
'@backstage/plugin-search-react': patch
|
||||
'@backstage/plugin-azure-sites': patch
|
||||
'@backstage/plugin-firehydrant': patch
|
||||
'@backstage/plugin-cloudbuild': patch
|
||||
'@backstage/plugin-kubernetes': patch
|
||||
'@backstage/plugin-lighthouse': patch
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
'@backstage/plugin-tech-radar': patch
|
||||
'@backstage/plugin-dynatrace': patch
|
||||
'@backstage/plugin-gcalendar': patch
|
||||
'@backstage/plugin-pagerduty': patch
|
||||
'@backstage/plugin-shortcuts': patch
|
||||
'@backstage/plugin-sonarqube': patch
|
||||
'@backstage/plugin-xcmetrics': patch
|
||||
'@backstage/plugin-airbrake': patch
|
||||
'@backstage/plugin-api-docs': patch
|
||||
'@backstage/plugin-circleci': patch
|
||||
'@backstage/plugin-graphiql': patch
|
||||
'@backstage/plugin-newrelic': patch
|
||||
'@backstage/plugin-periskop': patch
|
||||
'@backstage/plugin-techdocs': patch
|
||||
'@backstage/plugin-bitrise': patch
|
||||
'@backstage/plugin-catalog': patch
|
||||
'@backstage/plugin-explore': patch
|
||||
'@backstage/plugin-jenkins': patch
|
||||
'@backstage/plugin-rollbar': patch
|
||||
'@backstage/plugin-allure': patch
|
||||
'@backstage/plugin-badges': patch
|
||||
'@backstage/plugin-bazaar': patch
|
||||
'@backstage/plugin-search': patch
|
||||
'@backstage/plugin-sentry': patch
|
||||
'@backstage/plugin-fossa': patch
|
||||
'@backstage/plugin-ilert': patch
|
||||
'@backstage/plugin-kafka': patch
|
||||
'@backstage/plugin-gocd': patch
|
||||
'@backstage/plugin-home': patch
|
||||
'@backstage/plugin-todo': patch
|
||||
'@backstage/plugin-adr': patch
|
||||
'@backstage/plugin-org': patch
|
||||
---
|
||||
|
||||
Small tweaks to remove warnings in the console during development (mainly focusing on techdocs)
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@techdocs/cli': patch
|
||||
---
|
||||
|
||||
Adding global-agent to enable the ability to publish through a proxy
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
---
|
||||
|
||||
Allow replacement of the BuiltinKindsEntityProcessor which enables customization of schema validation and connections emitted.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog': minor
|
||||
---
|
||||
|
||||
Added `isEntityWith` condition helper for `EntitySwitch` case statements.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Add `onboard` command. While still in development, this command aims to guide users in setting up their Backstage App.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-shortcuts': patch
|
||||
---
|
||||
|
||||
Allow external links to be added as shortcuts
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder': minor
|
||||
---
|
||||
|
||||
Allow `TemplateListPage` and `TemplateWizardPage` to be passed in as props
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/plugin-techdocs-backend': patch
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
'@backstage/plugin-explore-backend': patch
|
||||
---
|
||||
|
||||
Collator factories instantiated in new backend system modules and now marked as deprecated. Will be continued to be exported publicly until the new backend system is fully rolled out.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-common': patch
|
||||
---
|
||||
|
||||
Improve GitlabUrlReader to only load requested sub-path
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder': minor
|
||||
---
|
||||
|
||||
Added a `templateFilter` prop to the `<Router/>` component to allow for filtering of templates through a function.
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-react': minor
|
||||
'@backstage/plugin-scaffolder': minor
|
||||
---
|
||||
|
||||
Move `CategoryPicker` from `scaffolder` into `scaffolder-react`
|
||||
Move `ContextMenu` into `scaffolder-react` and rename it to `ScaffolderPageContextMenu`
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-react': minor
|
||||
---
|
||||
|
||||
To offer better customization options, `ScaffolderPageContextMenu` takes callbacks as props instead of booleans
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
Fixed the font color on `BackstageHeaderLabel` to respect the active page theme.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-common': patch
|
||||
---
|
||||
|
||||
Define optional `backstage:permissions` property to parameters and steps used to authorize part of the template using the permission framework
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-graphiql': patch
|
||||
---
|
||||
|
||||
Allow to pass lazy GraphQL endpoint URL
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-search-backend-node': minor
|
||||
---
|
||||
|
||||
Exports services and extension points that can be used with the new backend system. For documentation on how to migrate, check out the [how to migrate to the new backend system guide](../docs/features/search/how-to-guides.md#how-to-migrate-to-use-search-together-with-the-new-backend-system).
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-react': minor
|
||||
---
|
||||
|
||||
`scaffolder/next`: Export the `TemplateGroupFilter` and `TemplateGroups` and make an extensible component
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/plugin-search-backend-module-techdocs': minor
|
||||
'@backstage/plugin-search-backend-module-catalog': minor
|
||||
'@backstage/plugin-search-backend-module-explore': minor
|
||||
---
|
||||
|
||||
Package introduced to export search backend modules that can be used with the new backend system to extend search with plugin specific functionality, such as collators. For documentation on how to migrate, check out the [how to migrate to the new backend system guide](../docs/features/search/how-to-guides.md#how-to-migrate-to-use-search-together-with-the-new-backend-system).
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-kubernetes-common': patch
|
||||
---
|
||||
|
||||
Introduced proxy permission types to be used with the kubernetes proxy endpoint's permission framework integration.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/repo-tools': patch
|
||||
---
|
||||
|
||||
Log API report instructions when api-report is missing.
|
||||
+4
-3
@@ -13,6 +13,7 @@ yarn.lock @backstage/maintainers @back
|
||||
/docs/features/search @backstage/techdocs-core
|
||||
/docs/features/techdocs @backstage/techdocs-core
|
||||
/docs/plugins/integrating-search-into-plugins.md @backstage/techdocs-core
|
||||
/packages/cli/src/commands/onboard @backstage/sharks
|
||||
/packages/techdocs-cli @backstage/techdocs-core
|
||||
/packages/techdocs-cli-embedded-app @backstage/techdocs-core
|
||||
/plugins/adr @backstage/maintainers @kuangp
|
||||
@@ -60,9 +61,9 @@ yarn.lock @backstage/maintainers @back
|
||||
/plugins/jenkins-backend @backstage/maintainers @timja
|
||||
/plugins/kafka @backstage/maintainers @nirga @andrewthauer
|
||||
/plugins/kafka-backend @backstage/maintainers @nirga @andrewthauer
|
||||
/plugins/kubernetes @backstage/maintainers @backstage/warpspeed
|
||||
/plugins/kubernetes-* @backstage/maintainers @backstage/warpspeed
|
||||
/plugins/microsoft-calendar @backstage/maintainers @abhay-soni-developer
|
||||
/plugins/kubernetes @backstage/maintainers @backstage/kubernetes-maintainers
|
||||
/plugins/kubernetes-* @backstage/maintainers @backstage/kubernetes-maintainers
|
||||
/plugins/microsoft-calendar @backstage/maintainers @abhay-soni-developer @NishkarshRaj
|
||||
/plugins/newrelic-dashboard @backstage/maintainers @mufaddal7
|
||||
/plugins/playlist @backstage/maintainers @kuangp
|
||||
/plugins/playlist-* @backstage/maintainers @kuangp
|
||||
|
||||
@@ -82,6 +82,7 @@ Debounce
|
||||
debuggability
|
||||
declaratively
|
||||
deduplicated
|
||||
deliverables
|
||||
dependabot
|
||||
deps
|
||||
destructured
|
||||
@@ -158,6 +159,7 @@ img
|
||||
incentivised
|
||||
Indal
|
||||
indexable
|
||||
ingestors
|
||||
inlined
|
||||
inlinehilite
|
||||
integrator's
|
||||
@@ -367,6 +369,7 @@ templaters
|
||||
Templaters
|
||||
TFRecord
|
||||
theia
|
||||
threenager
|
||||
thumbsup
|
||||
todo
|
||||
todos
|
||||
@@ -403,6 +406,7 @@ validator
|
||||
validators
|
||||
varchar
|
||||
VMware
|
||||
Vodafone
|
||||
VPCs
|
||||
VSCode
|
||||
Wayfair
|
||||
|
||||
@@ -234,4 +234,5 @@ _You can do this by using the [Adopter form](https://info.backstage.spotify.com/
|
||||
| [N26](https://n26.com) | [Alexei Timofti](https://www.linkedin.com/in/alexeitimofti) | We use Backstage for our service catalog and are actively looking into adopting other plugins like TechDocs, TechInsights and Software Templates. |
|
||||
| [The LEGO Group](https://www.lego.com) | [Waqas Ali](https://www.linkedin.com/in/waqasali47) | We are building our internal develper portal on top of Backstage. |
|
||||
| [CORS.gmbh](https://www.cors.gmbh) | [@dpfaffenbauer](https://github.com/dpfaffenbauer) | Developer Portal for our Projects we develop for our Customers and Hosting them On Kubernetes. |
|
||||
| [Comcast](https://comcast.github.io/) | [Ryan Emerle](https://github.com/remerle) | Developer portal enabling discovery of products, services, and documentation throughout the enterprise to ultimately reduce friction and improve time-to-market. |
|
||||
|
||||
|
||||
+206
-61
@@ -1,88 +1,233 @@
|
||||
# Process for becoming a maintainer
|
||||
# Project Areas
|
||||
|
||||
## a) Your organization is not yet a maintainer
|
||||
The Backstage project is divided into several project areas, each covering particular parts of the project. The main driver for each area is ownership of code in the main Backstage repository, as well as other repositories in the Backstage GitHub organization. Each area has a set of maintainers and repository content that they own. There may be no overlap in ownership between areas, which means that any given line in the GitHub code owners file should have only one owner specified. Each area is represented by a team in the Backstage GitHub organization. Apart from certain project-wide concerns, such as the release process, each area is self-governing and chooses their own ways of working. Project areas may also have special interest groups (SIGs) related to their area, but this is not required.
|
||||
|
||||
- Express interest to the sponsors that your organization is interested in becoming a maintainer. Becoming a maintainer generally means that you are going to be spending substantial time on Backstage for the foreseeable future. You should have domain expertise and be extremely proficient in TypeScript.
|
||||
- We will expect you to start contributing increasingly complicated PRs, under the guidance of the existing maintainers.
|
||||
- We may ask you to do some PRs from our backlog.
|
||||
- As you gain experience with the code base and our standards, we will ask you to do code reviews for incoming PRs.
|
||||
- After a period of approximately 2-3 months of working together and making sure we see eye to eye, the existing sponsors and maintainers will confer and decide whether to grant maintainer status or not. We make no guarantees on the length of time this will take, but 2-3 months is the approximate goal.
|
||||
The project areas as well as their maintainers are listed in the [OWNERS.md](./OWNERS.md) file.
|
||||
|
||||
## b) Your organization is currently a maintainer
|
||||
Each project area must have at least one maintainer. Project area maintainers may have shared ownership with the core maintainers, which in that case is considered an incubating area. The project area maintainers help drive work forward in the area, but they might not yet feel ready to take on ownership. The goal should generally be that these project area maintainers eventually become sole maintainers of the project area. This is to allow for a more smooth onboarding and transition of ownership, where members of the community might for example be new to open source maintainership.
|
||||
|
||||
To become a maintainer you need to demonstrate the following:
|
||||
## Adding new project areas
|
||||
|
||||
- First decide whether your organization really needs more people with maintainer access. Valid reasons are "blast radius", a large organization that is working on multiple unrelated projects, etc.
|
||||
- Contact a sponsor for your organization and express interest.
|
||||
- Start doing PRs and code reviews under the guidance of your maintainer.
|
||||
- After a period of 1-2 months the existing sponsors will discuss granting maintainer access.
|
||||
- Maintainer access can be upgraded to sponsor access after another conference of the existing sponsors.
|
||||
Project areas are added by nominating new maintainers for that area. See the sections for becoming a [Project Area Maintainer](#project-area-maintainer).
|
||||
|
||||
# Maintainer responsibilities
|
||||
Project areas may also by added by splitting existing areas. Every area that is created through this process must have at least one maintainer.
|
||||
|
||||
- Monitor email aliases.
|
||||
- Monitor Discord (delayed response is perfectly acceptable).
|
||||
- Triage GitHub issues and perform pull request reviews for other maintainers and the community.
|
||||
- Triage build issues - file issues for known flaky builds or bugs, and either fix or find someone to fix any master build breakages.
|
||||
- During GitHub issue triage, apply all applicable ([labels](https://github.com/backstage/backstage/labels)) to each new issue. Labels are extremely useful for future issue follow-up. Which labels to apply is somewhat subjective so just use your best judgment. A few of the most important labels that are not self-explanatory are:
|
||||
- good first issue: Mark any issue that can reasonably be accomplished by a new contributor with this label.
|
||||
- help wanted: Unless it is immediately obvious that someone is going to work on an issue (and if so assign it), mark it help wanted.
|
||||
- Make sure that ongoing PRs are moving forward at the right pace or closing them.
|
||||
- Participate when called upon in the security release process. Note that although this should be a rare occurrence, if a serious vulnerability is found, the process may take up to several full days of work to implement. This reality should be taken into account when discussing time commitment obligations with employers.
|
||||
- In general, continue to be willing to spend at least 25% of one's time working on Backstage (~1.25 business days per week).
|
||||
- We currently maintain an "on-call" rotation within the maintainers. Each on-call is 1 week. Although all maintainers are welcome to perform all of the above tasks, it is the on-call maintainer's responsibility to triage incoming issues/questions and marshal ongoing work forward. To reiterate, it is not the responsibility of the on-call maintainer to answer all questions and do all reviews, but it is their responsibility to make sure that everything is being actively covered by someone.
|
||||
## Removing project areas
|
||||
|
||||
# When does a maintainer lose maintainer status
|
||||
Project areas are removed by removing all maintainers for that area and removing the corresponding team from the Backstage GitHub organization. The project area can be re-added later if there is a need for it. Reasons for removal may include lack of activity, lack of maintainers, or lack of relevance to the project.
|
||||
|
||||
If a maintainer is no longer interested or cannot perform the maintainer duties listed above, they should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of the sponsors and maintainers per the voting process below.
|
||||
# Project Roles
|
||||
|
||||
# End User Sponsors
|
||||
## Contributor
|
||||
|
||||
## Role of a Backstage End User Sponsor
|
||||
A Contributor contributes directly to the project and adds value to it. Contributions need not be code. People at the Contributor level may be new contributors, or they may only contribute occasionally.
|
||||
|
||||
- Provide support for Backstage by removing blockers, securing funding, providing advocacy, feedback, and ensuring project continuity and long term success.
|
||||
- Assist Backstage maintainers in prioritizing upcoming roadmap items and planned work.
|
||||
- Provide neutral mediation for any disputes that arise as part of the project.
|
||||
### Responsibilities
|
||||
|
||||
## Backstage End User Sponsor Membership
|
||||
- Follow the [CNCF CoC](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)
|
||||
- Follow the project [contributing guide](CONTRIBUTING.md)
|
||||
|
||||
### How to get involved
|
||||
|
||||
- Participate in community discussions
|
||||
- Help other users
|
||||
- Submit bug reports
|
||||
- Comment on issues
|
||||
- Try out new releases
|
||||
- Attend community events
|
||||
|
||||
### How to contribute
|
||||
|
||||
- Report and sometimes resolve issues
|
||||
- Occasionally submit PRs
|
||||
- Contribute to the documentation
|
||||
- Show up at meetings, take notes
|
||||
- Answer questions from other community members
|
||||
- Submit feedback on issues and PRs
|
||||
- Test releases and patches and submit reviews
|
||||
- Run or help run events
|
||||
- Promote the project in public
|
||||
|
||||
## Organization Member
|
||||
|
||||
An org member is a frequent contributor that has become a member of the Backstage GitHub organization. In addition to the responsibilities of contributors, an org member is also expected to be reasonably active in the community through continuous contributions of any type.
|
||||
|
||||
An Organization Member must meet the responsibilities and has the requirements of a Contributor.
|
||||
|
||||
### Responsibilities
|
||||
|
||||
- Continues to contribute regularly, as demonstrated by having at least 10 GitHub contributions per year in [Devstats](https://backstage.devstats.cncf.io/d/48/users-statistics-by-repository-group?orgId=1&var-period=y&var-metric=contributions&var-repogroup_name=All&from=now-1y&to=now&var-users=All), or contributions of a similar effort that might not be captured in Devstats.
|
||||
|
||||
### Requirements
|
||||
|
||||
- Must have at least 10 contributions to the projects in the form of:
|
||||
- Accepted PRs
|
||||
- Helpful PR reviews
|
||||
- Resolving GitHub issues
|
||||
- Or some equivalent contributions to the project
|
||||
- Must have been contributing for at least 3 months
|
||||
- Or is the member of a team that owns a project area, in which case the above requirements do not apply and the member is instead vetted by the project area maintainers
|
||||
|
||||
### Becoming an Organization Member
|
||||
|
||||
Open an issue towards [the community repository](https://github.com/backstage/community) using the [org membership request template](https://github.com/backstage/community/issues/new?template=org_member.yaml&title=Org+Member%3A+%3Cyour-github-login%3E).
|
||||
|
||||
### Privileges
|
||||
|
||||
- Membership in the Backstage GitHub organization
|
||||
|
||||
## Plugin Maintainer
|
||||
|
||||
A Plugin Maintainer is responsible for maintaining an individual Backstage plugin or module. This includes reviewing contributions and responding to issues towards an individual plugin, as well as keeping the plugin up to date.
|
||||
|
||||
Plugin Maintainer is a lightweight form of ownership that is primarily reflected though code owners of the plugin packages in the [CODEOWNERS](./.github/CODEOWNERS) file. Each plugin can have one or more maintainers. If a plugin becomes a significant part of the Backstage ecosystem, it may be promoted to be a distinct project area instead.
|
||||
|
||||
A Plugin Maintainer has all the rights and responsibilities of an Organization Member.
|
||||
|
||||
### Responsibilities
|
||||
|
||||
- Review the majority of PRs towards the plugin
|
||||
- Respond to GitHub issues related to the plugin
|
||||
- Keep the plugin up-to-date with Backstage libraries and other dependencies
|
||||
- Follow the [reviewing guide](REVIEWING.md)
|
||||
|
||||
### Requirements
|
||||
|
||||
- Is an Organization Member
|
||||
- Display knowledge of Backstage's review process and best practices for plugin design
|
||||
- Is supportive of new and occasional contributors and helps get useful PRs in shape to merge
|
||||
|
||||
### Privileges
|
||||
|
||||
- GitHub code owner of the plugin directory, with rights to approve and merge PRs towards the plugin
|
||||
|
||||
### Becoming a Plugin Maintainer
|
||||
|
||||
To become a Plugin Maintainer, you first need to be an Organization Member. You can then file a pull request towards [CODEOWNERS.md](./.github/CODEOWNERS) requesting to be added as a code owner of the plugin directory. Existing code owners of that plugin alongside the core maintainers will then review the request.
|
||||
|
||||
## Project Area Maintainer
|
||||
|
||||
Project Area Maintainers are owners of a particular project area. They are expected to review and merge pull requests towards their area, and also drive development and manage tech health. A Project Area Maintainer also need to commit a certain number of hours per month towards the project, and exercise judgment for the good of the project, independent of their employer. Project Area Maintainers should also mentor new maintainers and participate in and lead community meetings related to their area. New Project Area Maintainers need to be approved by the existing project area maintainers, or the core maintainers if it is a new area.
|
||||
|
||||
The maintainers of a project area may be represented by a team in external organization. In this case, the state as a project area maintainer is tied to the membership in that team. New members of the team may automatically be added as maintainers, as well as removed when they leave. This process is governed autonomously by the team of project area maintainers.
|
||||
|
||||
A Project Area Maintainer has all the rights and responsibilities of an Organization Member.
|
||||
|
||||
### Responsibilities
|
||||
|
||||
- Review PRs towards their project area. Project area maintainers are expected to review at least 20 PRs per year, or the majority of all PRs towards the area, if it is less than 20
|
||||
- Follow the [reviewing guide](REVIEWING.md)
|
||||
- Triage and respond to issues related to their project area
|
||||
- Mentor new project area maintainers
|
||||
- Write refactoring PRs
|
||||
- Determine strategy and policy for the project area
|
||||
- Participate in or leading community meetings related to their project area
|
||||
|
||||
### Requirements
|
||||
|
||||
- Is an Organization Member
|
||||
- Have made at least 5 meaningful contributions towards the project area
|
||||
- Demonstrates knowledge of their project area, and how it fits into the larger Backstage project
|
||||
- Is able to exercise judgment for the good of the project, independent of their employer, friends, or team
|
||||
- Mentors other contributors and project area maintainers
|
||||
- Can commit to spending at least 16 hours per month working on the project, preferably distributed evenly across the month
|
||||
|
||||
### Privileges
|
||||
|
||||
- Approve and merge PRs towards their project area
|
||||
- Drive the direction and roadmap of their project area
|
||||
|
||||
### Becoming a Project Area Maintainer
|
||||
|
||||
If you are interested in becoming a project area maintainer, reach out to the existing maintainers for that area. If you wish to become a maintainer for a new area, reach out to the core maintainers.
|
||||
|
||||
Any current project area maintainer or core maintainer may nominate a new project area maintainer by opening a PR towards the [OWNERS.md](OWNERS.md) file. A majority of the project area maintainers for that area must approve the PR. If there are no existing maintainers for that area, the PR must be approved by a majority of the core maintainers.
|
||||
|
||||
## Core Maintainer
|
||||
|
||||
Core Maintainers are responsible for the Backstage project as a whole. They help review and merge project-level pull requests as well as coordinate work affecting multiple project areas. A core maintainer needs to commit the majority of their working time towards the project, and exercise judgment for the good of the project, independent of their employer. Core maintainers should also mentor and seek out new maintainers, lead community meetings, and communicate with the CNCF on behalf of the project. To become a core maintainer one needs to have been the maintainer of a number of different project areas, demonstrate a deep knowledge of large parts of the Backstage project, and be backed by the existing core maintainers.
|
||||
|
||||
A Core Maintainer have all the rights and responsibilities of a Project Area Maintainer.
|
||||
|
||||
### Responsibilities
|
||||
|
||||
- Take part in the incoming issue and PR triage and review process. PRs are shared equally among all maintainers
|
||||
- Mentor new Project Area Maintainers and Plugin Maintainers
|
||||
- Drive refactoring and manage tech health across the entire project
|
||||
- Participate in CNCF maintainer activities
|
||||
- Respond to security incidents in accordance to our [security policy](./SECURITY.md)
|
||||
- Determine strategy and policy for the project
|
||||
- Participate in or leading community meetings
|
||||
|
||||
### Requirements
|
||||
|
||||
- Experience as a Project Area Maintainer for at least 6 months
|
||||
- Demonstrates a broad knowledge of the project across multiple areas
|
||||
- Is able to exercise judgment for the good of the project, independent of their employer, friends, or team
|
||||
- Mentors other contributors
|
||||
- Can commit to spending at least 10 days per month working on the project
|
||||
|
||||
### Privileges
|
||||
|
||||
- Approve PRs that fall outside any specific project area
|
||||
- Merge PRs to any area of the project
|
||||
- Represent the project in public as a Maintainer
|
||||
- Communicate with the CNCF on behalf of the project
|
||||
- Have a vote in Maintainer decision-making meetings
|
||||
|
||||
### Becoming a Core Maintainer
|
||||
|
||||
Any core maintainer or end user sponsor may nominate a new core maintainer by opening a PR towards the [OWNERS.md](OWNERS.md) file. Core maintainers must be approved by a majority of the existing core maintainers and end user sponsors.
|
||||
|
||||
## End User Sponsors
|
||||
|
||||
### Role of a Backstage End User Sponsor
|
||||
|
||||
- Provide support for Backstage by removing blockers, securing funding, providing advocacy, feedback, and ensuring project continuity and long term success
|
||||
- Assist Backstage maintainers in prioritizing upcoming roadmap items and planned work
|
||||
- Provide neutral mediation for any disputes that arise as part of the project
|
||||
|
||||
### Backstage End User Sponsor Membership
|
||||
|
||||
The End User Sponsors group comprises at most 5 people. To be eligible for membership in the group, you or the company where you work you must:
|
||||
|
||||
- Be responsible for and end user of a production Backstage deployment of non-trivial size
|
||||
- Be active contributors to the open source project
|
||||
- Be willing and able to attend regularly-scheduled End User Sponsor meetings
|
||||
- Abide by [Backstage’s Code of Conduct](./CODE_OF_CONDUCT.md).
|
||||
- Abide by [CNCF CoC](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)
|
||||
|
||||
Candidates for membership will be nominated by current Sponsor members or by Backstage maintainers. If there are more nominations than Sponsor seats remaining, existing sponsors shall vote on the candidates, and the candidates with the most votes will become Sponsors. Any ties will be broken by current Backstage sponsors.
|
||||
|
||||
# Reviewers
|
||||
|
||||
The project also contains a team called [@backstage/reviewers](https://github.com/orgs/backstage/teams/reviewers). This is the team of people who are the fallback in [`CODEOWNERS`](./.github/CODEOWNERS). This team will typically contain the maintainers, and a small number of additional people who are permitted to approve and merge pull requests. The purpose of this group is to offload some of the review work from the maintainers, simplifying and speeding up the review process for contributors.
|
||||
|
||||
This responsibility is distinct from the maintainer role. A reviewer must not approve and merge changes that have a level of impact that a maintainer should oversee; see below for clarification. For that class of changes, a reviewer can still review the pull request thoroughly without approving it (e.g. with a comment on the pull request), and is expected to notify `@backstage/maintainers` for final approval. Note that it is best to not use the GitHub review approve functionality for this, since that would let Hall of Fame members self-merge the pull request before maintainers get the chance to look at it.
|
||||
|
||||
The following is a non-exhaustive list of types of change, for which a reviewer should defer final decision and merge to a maintainer:
|
||||
|
||||
- A larger refactoring that significantly affects the structure of/between packages
|
||||
- Changes that settle or alter the trajectory of contested ongoing topics in issues or elsewhere
|
||||
- Changes that affect the [Architecture Decision Records](./docs/architecture-decisions)
|
||||
- Changes to APIs that have large customer impact, such as the core APIs in `@backstage/core-*` packages, or significant `@backstage/cli` changes.
|
||||
- Pull requests whose build checks are not passing fully
|
||||
- Additions and removals of entire packages
|
||||
- Releases (e.g. pull requests titled `Version Packages`)
|
||||
|
||||
A maintainer may suggest an addition to the reviewers team by opening a pull request that modifies [`OWNERS.md`](./OWNERS.md) accordingly. Prospective reviewers are not expected to do this themselves, but should rather ask a maintainer to sponsor their addition. All of the maintainers and sponsors are called to vote on the addition (see the section below about voting). If the vote passes, the pull request can be approved and merged, and the corresponding addition to the GitHub team can be made.
|
||||
|
||||
A reviewer can elect to remove themselves from the reviewers group by opening, or asking a maintainer to open, a pull request that modifies [`OWNERS.md`](./OWNERS.md) accordingly. A maintainer will approve and merge the pull request, and the corresponding removal from the GitHub team can be made.
|
||||
|
||||
A maintainer can call on the other maintainers and sponsors for a vote to remove a reviewer (see the section below about conflict resolution and voting). If the vote passes, a maintainer creates a pull request that modifies [`OWNERS.md`](./OWNERS.md) accordingly. After approval by another maintainer, the pull request can be merged, and the corresponding removal from the GitHub team can be made.
|
||||
|
||||
# Conflict resolution and voting
|
||||
|
||||
In general, we prefer that technical issues and membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the sponsors and maintainers can be called in to decide an issue. If the sponsors and maintainers themselves cannot decide an issue, the issue will be resolved by voting.
|
||||
In general, we prefer that technical issues and membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the sponsors and core maintainers can be called in to decide an issue. If the sponsors and maintainers themselves cannot decide an issue, the issue will be resolved by voting.
|
||||
|
||||
In all cases in this document where voting is mentioned, the voting process is a simple majority in which each sponsor receives two votes and each maintainer receives one vote. If such a majority is reached, the vote is said to have _passed_.
|
||||
In all cases in this document where voting is mentioned, the voting process is a simple majority in which each sponsor receives two votes and each core maintainer receives one vote. If such a majority is reached, the vote is said to have _passed_.
|
||||
|
||||
# Adding new projects to the Backstage GitHub organization
|
||||
## Inactivity
|
||||
|
||||
New projects will be added to the Backstage organization via GitHub issue discussion in one of the existing projects in the organization. Once sufficient discussion has taken place (~3-5 business days but depending on the volume of conversation), the maintainers of the project where the issue was opened (since different projects in the organization may have different maintainers) will decide whether the new project should be added. See the section above on voting if the maintainers cannot easily decide.
|
||||
It is important for contributors to be and stay active to set an example and show commitment to the project. Inactivity is harmful to the project as it may lead to unexpected delays, contributor attrition, and a loss of trust in the project.
|
||||
|
||||
Inactivity is measured by periods of no contributions for longer than:
|
||||
|
||||
- Core Maintainer: 2 months
|
||||
- Project Area Maintainer: 4 months
|
||||
- Plugin Maintainer: 6 months
|
||||
- Organization Member: 8 months
|
||||
|
||||
Consequences of being inactive include:
|
||||
|
||||
- Involuntary removal or demotion
|
||||
- Being asked to move to Emeritus status
|
||||
|
||||
## Involuntary Removal or Demotion
|
||||
|
||||
Involuntary removal/demotion of a contributor happens when responsibilities and requirements aren't being met. This may include repeated patterns of inactivity, extended period of inactivity, a period of failing to meet the requirements of your role, and/or a violation of the Code of Conduct. This process is important because it protects the community and its deliverables while also opens up opportunities for new contributors to step in.
|
||||
|
||||
Involuntary removal or demotion is handled through a vote by a majority of the current Core Maintainers. Some aspects of this process may be automated, such as removal after periods of inactivity.
|
||||
|
||||
## Stepping Down/Emeritus Process
|
||||
|
||||
If and when contributors' commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs moving to emeritus status (completely stepping away from the project).
|
||||
|
||||
Contact the Maintainers about changing to Emeritus status, or reducing your contributor level.
|
||||
|
||||
@@ -1,43 +1,79 @@
|
||||
- See [CONTRIBUTING.md](CONTRIBUTING.md) for general contribution guidelines.
|
||||
- See [GOVERNANCE.md](GOVERNANCE.md) for governance guidelines and responsibilities.
|
||||
|
||||
This page lists all active sponsors and maintainers.
|
||||
## Core Maintainers
|
||||
|
||||
# Sponsors
|
||||
Team: @backstage/maintainers
|
||||
|
||||
- Niklas Gustavsson ([protocol7](https://github.com/protocol7)) (ngn@spotify.com)
|
||||
- Dave Zolotusky ([dzolotusky](https://github.com/dzolotusky)) (dzolo@spotify.com)
|
||||
- Lee Mills ([leemills83](https://github.com/leemills83)) (leem@spotify.com)
|
||||
| Maintainer | Organization | GitHub | Discord |
|
||||
| --------------- | ------------ | ----------------------------------------------- | ------------- |
|
||||
| Patrik Oldsberg | Spotify | [Rugvip](https://github.com/Rugvip) | `Rugvip#0019` |
|
||||
| Fredrik Adelöw | Spotify | [freben](https://github.com/freben) | `freben#3926` |
|
||||
| Ben Lambert | Spotify | [benjdlambert](https://github.com/benjdlambert) | `blam#2159` |
|
||||
| Johan Haals | Spotify | [jhaals](https://github.com/jhaals) | `Johan#0679` |
|
||||
|
||||
# Maintainers
|
||||
## Project Areas
|
||||
|
||||
- Patrik Oldsberg ([rugvip](https://github.com/rugvip)) (Discord: @Rugvip)
|
||||
- Fredrik Adelöw ([freben](https://github.com/freben)) (Discord: @freben)
|
||||
- Ben Lambert ([benjdlambert](https://github.com/benjdlambert)) (Discord: @blam)
|
||||
- Johan Haals ([jhaals](https://github.com/jhaals)) (Discord: @jhaals)
|
||||
These are the separate project areas of Backstage, each with their own project area maintainers
|
||||
|
||||
# Reviewers
|
||||
### Catalog
|
||||
|
||||
See [`GOVERNANCE.md`](./GOVERNANCE.md) for details about how the reviewers team
|
||||
works.
|
||||
Team: @backstage/catalog-maintainers
|
||||
|
||||
- Patrik Oldsberg ([rugvip](https://github.com/rugvip)) (Discord: @Rugvip)
|
||||
- Fredrik Adelöw ([freben](https://github.com/freben)) (Discord: @freben)
|
||||
- Ben Lambert ([benjdlambert](https://github.com/benjdlambert)) (Discord: @blam)
|
||||
- Johan Haals ([jhaals](https://github.com/jhaals)) (Discord: @jhaals)
|
||||
- Himanshu Mishra ([OrkoHunter](https://github.com/OrkoHunter)) (Discord: @OrkoHunter)
|
||||
- Tim Hansen ([timbonicus](https://github.com/timbonicus)) (Discord: @timbonicus)
|
||||
| Name | Organization | Team | GitHub | Discord |
|
||||
| ---- | ------------ | --------- | ---------------------------- | ------- |
|
||||
| TBD | Spotify | Chipmunks | [TBD](http://github.com/TBD) | - |
|
||||
|
||||
# Emeritus maintainers
|
||||
### Kubernetes
|
||||
|
||||
- Stefan Ålund ([stefanalund](https://github.com/stefanalund)) (Discord: @stalund)
|
||||
Team: @backstage/kubernetes-maintainers
|
||||
|
||||
# Hall of Fame
|
||||
Scope: The Kubernetes plugin and the base it provides for other plugins to build upon.
|
||||
|
||||
People that have made significant contributions to the project and earned write access.
|
||||
| Name | Organization | Team | GitHub | Discord |
|
||||
| -------------- | ------------ | ---- | ---------------------------------------- | ------------ |
|
||||
| Matthew Clarke | Spotify | | [mclarke47](http://github.com/mclarke47) | mclarke#0725 |
|
||||
|
||||
- Andrew Thauer - Wealthsimple (GitHub: [andrewthauer](https://github.com/andrewthauer))
|
||||
- Oliver Sand - SDA SE (GitHub: [Fox32](https://github.com/Fox32))
|
||||
- David Tuite - Roadie (GitHub: [dtuite](https://github.com/dtuite))
|
||||
- Adam Harvey - Cisco (GitHub: [adamdmharvey](https://github.com/adamdmharvey))
|
||||
- Dominik Henneke - SDA SE (GitHub: [dhenneke](https://github.com/dhenneke))
|
||||
### TechDocs
|
||||
|
||||
Team: @backstage/techdocs-maintainers
|
||||
|
||||
| Name | Organization | Team | GitHub | Discord |
|
||||
| ---- | ------------ | ------------ | ---------------------------- | ------- |
|
||||
| TBD | Spotify | Pulp Fiction | [TBD](http://github.com/TBD) | - |
|
||||
|
||||
### Search
|
||||
|
||||
Team: @backstage/search-maintainers
|
||||
|
||||
| Name | Organization | Team | GitHub | Discord |
|
||||
| ---- | ------------ | ---- | ---------------------------- | ------- |
|
||||
| TBD | Spotify | BUX | [TBD](http://github.com/TBD) | - |
|
||||
|
||||
## Sponsors
|
||||
|
||||
| Name | Organization | GitHub | Email |
|
||||
| ----------------- | ------------ | ------------------------------------------- | ----------------- |
|
||||
| Niklas Gustavsson | Spotify | [protocol7](https://github.com/protocol7) | ngn@spotify.com |
|
||||
| Dave Zolotusky | Spotify | [dzolotusky](https://github.com/dzolotusky) | dzolo@spotify.com |
|
||||
| Lee Mills | Spotify | [leemills83](https://github.com/leemills83) | leem@spotify.com |
|
||||
|
||||
## Organization Members
|
||||
|
||||
| Name | Organization | GitHub | Discord |
|
||||
| --------------- | ------------------------ | ----------------------------------------------- | ------------------------------ |
|
||||
| Adam Harvey | Cisco | [adamdmharvey](https://github.com/adamdmharvey) | `adamharvey#3739` |
|
||||
| Andre Wanlin | Keyloop | [awanlin](https://github.com/awanlin) | `Ahhhndre#3095` |
|
||||
| Andrew Thauer | Wealthsimple | [andrewthauer](https://github.com/andrewthauer) | `andrewthauer#3060` |
|
||||
| Brian Fletcher | RoadieHQ | [punkle](https://github.com/punkle) | `Brian Fletcher#7051` |
|
||||
| David Tuite | Roadie | [dtuite](https://github.com/dtuite) | `David Tuite (roadie.io)#1010` |
|
||||
| Jussi Hallila | Roadie | [Xantier](https://github.com/Xantier) | `Xantier#0086` |
|
||||
| Mark Avery | Cvent | [webark](https://github.com/webark) | `webark#8471` |
|
||||
| Phil Kuang | FactSet Research Systems | [kuangp](https://github.com/kuangp) | `pkuang#3202` |
|
||||
| Taras Mankovski | Frontside | [taras](https://github.com/taras) | `tarasm#1256` |
|
||||
|
||||
## Emeritus Core Maintainers
|
||||
|
||||
| Maintainer | Organization | GitHub | Discord |
|
||||
| ------------ | ------------ | --------------------------------------------- | -------------- |
|
||||
| Stefan Ålund | Spotify | [stefanalund](https://github.com/stefanalund) | `stalund#9602` |
|
||||
|
||||
@@ -75,6 +75,7 @@ export default async function createPlugin(
|
||||
logger: env.logger,
|
||||
config: env.config,
|
||||
catalogApi,
|
||||
permissions: env.permissions,
|
||||
}).build();
|
||||
return router;
|
||||
}
|
||||
|
||||
@@ -22,6 +22,7 @@ import {
|
||||
discoveryApiRef,
|
||||
googleAuthApiRef,
|
||||
useApi,
|
||||
identityApiRef,
|
||||
} from '@backstage/core-plugin-api';
|
||||
|
||||
const CLUSTER_NAME = ''; // use a known cluster name
|
||||
@@ -32,6 +33,10 @@ const token = await googleAuthApi.getAccessToken(
|
||||
'https://www.googleapis.com/auth/cloud-platform',
|
||||
);
|
||||
|
||||
// get a backstage ID token
|
||||
const identityApi = useApi(identityApiRef);
|
||||
const { token: userToken } = await identityApi.getCredentials();
|
||||
|
||||
const discoveryApi = useApi(discoveryApiRef);
|
||||
const kubernetesBaseUrl = await discoveryApi.getBaseUrl('kubernetes');
|
||||
const kubernetesProxyEndpoint = `${kubernetesBaseUrl}/proxy`;
|
||||
@@ -40,8 +45,9 @@ const kubernetesProxyEndpoint = `${kubernetesBaseUrl}/proxy`;
|
||||
await fetch(`${kubernetesProxyEndpoint}/api/v1/namespaces`, {
|
||||
method: 'GET',
|
||||
headers: {
|
||||
'X-Kubernetes-Cluster': CLUSTER_NAME,
|
||||
Authorization: `Bearer ${token}`,
|
||||
'Backstage-Kubernetes-Cluster': CLUSTER_NAME,
|
||||
'Backstage-Kubernetes-Authorization': `Bearer ${token}`,
|
||||
Authorization: `Bearer ${userToken}`,
|
||||
},
|
||||
});
|
||||
```
|
||||
@@ -49,16 +55,19 @@ await fetch(`${kubernetesProxyEndpoint}/api/v1/namespaces`, {
|
||||
## How it works
|
||||
|
||||
The proxy will interpret the
|
||||
[`X-Kubernetes-Cluster`
|
||||
header](https://backstage.io/docs/reference/plugin-kubernetes-backend.header_kubernetes_cluster)
|
||||
as the name of the cluster to target. This name will be compared to each cluster
|
||||
[`Backstage-Kubernetes-Cluster`](https://backstage.io/docs/reference/plugin-kubernetes-backend.header_kubernetes_cluster)
|
||||
header as the name of the cluster to target. This name will be compared to each cluster
|
||||
returned by all the configured [cluster
|
||||
locators](https://backstage.io/docs/features/kubernetes/configuration#clusterlocatormethods)
|
||||
-- the first cluster whose [`name` field](https://backstage.io/docs/features/kubernetes/configuration#clustersname) matches
|
||||
the value in the header will be targeted.
|
||||
|
||||
Then the request will be forwarded verbatim (but with the endpoint's base URL
|
||||
prefix stripped) to the cluster.
|
||||
Then the request will be forwarded to the cluster.
|
||||
|
||||
Overall, the only changes to each request are:
|
||||
|
||||
- the endpoint's base URL prefix is stripped.
|
||||
- the `Backstage-Kubernetes-Authorization` header becomes the `Authorization` header that is used when forwarding the request.
|
||||
|
||||
## Authentication
|
||||
|
||||
@@ -73,9 +82,59 @@ providers](https://backstage.io/docs/features/kubernetes/authentication#client-s
|
||||
The proxy has no provisions for mTLS, so it cannot be used to connect to
|
||||
clusters using the [x509 Client
|
||||
Certs](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs)
|
||||
authentication strategy. [Bearer
|
||||
tokens](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#putting-a-bearer-token-in-a-request)
|
||||
will be forwarded as-is.
|
||||
authentication strategy.\
|
||||
The current `/proxy` Implementation expects a
|
||||
[Bearer
|
||||
token](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#putting-a-bearer-token-in-a-request)
|
||||
to be provided as a `Backstage-Kubernetes-Authorization` header for a target cluster. This token will be used as the `Authorization` header when forwarding a request to a target cluster.
|
||||
|
||||
## How to disable the proxy endpoint via PermissionPolicy
|
||||
|
||||
The kubernetes plugin can disable the use of the `proxy` endpoint by leveraging the permission framework. This integration allows admins to use well defined PermissionPolicies to restrict the use of the endpoint all together. The `proxy` endpoint can return 403 errors even if it has a valid ID token attached that a cluster would authorize thus allowing integrators the confidence that Backstage is not accessing kubernetes clusters on behalf of undesired parties.
|
||||
|
||||
This feature assumes your backstage instance has enabled the [permissions framework](https://backstage.io/docs/permissions/getting-started)
|
||||
|
||||
A sample policy like:
|
||||
|
||||
[packages/backend/src/plugins/permissions.ts](https://github.com/backstage/backstage/blob/master/packages/backend/src/plugins/permission.ts)
|
||||
|
||||
```typescript
|
||||
import { BackstageIdentityResponse } from '@backstage/plugin-auth-node';
|
||||
import {
|
||||
AuthorizeResult,
|
||||
PolicyDecision,
|
||||
} from '@backstage/plugin-permission-common';
|
||||
import {
|
||||
PermissionPolicy,
|
||||
PolicyQuery,
|
||||
} from '@backstage/plugin-permission-node';
|
||||
|
||||
class KubernetesDenyAllProxyEndpointPolicy implements PermissionPolicy {
|
||||
async handle(
|
||||
request: PolicyQuery,
|
||||
user?: BackstageIdentityResponse,
|
||||
): Promise<PolicyDecision> {
|
||||
if (request.permission.name === 'kubernetes.proxy') {
|
||||
return {
|
||||
result: AuthorizeResult.DENY,
|
||||
};
|
||||
}
|
||||
return { result: AuthorizeResult.ALLOW };
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
would leverage the permission framework to return the following response:
|
||||
|
||||
```json
|
||||
{
|
||||
"error": {
|
||||
"name": "NotAllowedError"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
even if a valid ID token was attached that a cluster would authorize.
|
||||
|
||||
## Other known limitations
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ The TechDocs plugin has supported integrations to Search, meaning that it
|
||||
provides a default collator factory ready to be used.
|
||||
|
||||
The purpose of this guide is to walk you through how to register the
|
||||
[DefaultTechDocsCollatorFactory](https://github.com/backstage/backstage/blob/master/plugins/techdocs-backend/src/search/DefaultTechDocsCollatorFactory.ts)
|
||||
[DefaultTechDocsCollatorFactory](https://github.com/backstage/backstage/blob/de294ce5c410c9eb56da6870a1fab795268f60e3/plugins/techdocs-backend/src/search/DefaultTechDocsCollatorFactory.ts)
|
||||
in your App, so that you can get TechDocs documents indexed.
|
||||
|
||||
If you have been through the
|
||||
@@ -369,3 +369,31 @@ export const SearchModal = ({ toggleModal }: { toggleModal: () => void }) => (
|
||||
```
|
||||
|
||||
There are other more specific search results layout components that also accept result item extensions, check their documentation: [SearchResultList](https://backstage.io/storybook/?path=/story/plugins-search-searchresultlist--with-result-item-extensions) and [SearchResultGroup](https://backstage.io/storybook/?path=/story/plugins-search-searchresultgroup--with-result-item-extensions).
|
||||
|
||||
## How to migrate your backend installation to use Search together with the new backend system
|
||||
|
||||
> DISCLAIMER: The new backend system is in alpha, and so are the search backend support for the new backend system. We don't recommend you to migrate your backend installations to the new system yet. But if you want to experiment, this is the guide for you!
|
||||
|
||||
Recently, the Backstage maintainers [announced the new Backend System](https://backstage.io/blog/2023/02/15/backend-system-alpha). The search plugins are now migrated to support the new backend system. In this guide you will learn how to update your backend set up.
|
||||
|
||||
In packages/backend-next/index.ts
|
||||
|
||||
```ts
|
||||
import { searchPlugin } from '@backstage/plugin-search-backend/alpha';
|
||||
import { searchModuleElasticsearchEngine } from '@backstage/plugin-search-backend-module-elasticsearch/alpha';
|
||||
import { searchModuleCatalogCollator } from '@backstage/plugin-search-backend-module-catalog/alpha';
|
||||
import { searchModuleTechDocsCollator } from '@backstage/plugin-search-backend-module-techdocs/alpha';
|
||||
import { searchModuleExploreCollator } from '@backstage/plugin-search-backend-module-explore/alpha';
|
||||
|
||||
const backend = createBackend();
|
||||
// adding the search plugin to the backend
|
||||
backend.add(searchPlugin());
|
||||
// (optional) the default search engine is Lunr, if you want to extend the search backend with another search engine.
|
||||
backend.add(searchModuleElasticsearchEngine());
|
||||
// extending search with collator modules to start index documents, take in optional schedule parameters.
|
||||
backend.add(searchModuleCatalogCollator());
|
||||
backend.add(searchModuleTechDocsCollator());
|
||||
backend.add(searchModuleExploreCollator());
|
||||
|
||||
backend.start();
|
||||
```
|
||||
|
||||
@@ -170,6 +170,7 @@ its schema. There is a builtin processor that implements this for all known core
|
||||
kinds and matches the data against their fixed validation schema. This processor
|
||||
can be replaced when building the backend catalog using the `CatalogBuilder`,
|
||||
with a processor of your own that validates the data differently.
|
||||
This replacement processor must have a name that matches the builtin processor, `BuiltinKindsEntityProcessor`.
|
||||
|
||||
This type of extension is high risk, and may have high impact across the
|
||||
ecosystem depending on the type of change that is made. It is therefore not
|
||||
|
||||
@@ -506,9 +506,10 @@ import {
|
||||
processingResult,
|
||||
CatalogProcessor,
|
||||
CatalogProcessorEmit,
|
||||
LocationSpec,
|
||||
} from '@backstage/plugin-catalog-node';
|
||||
|
||||
import { LocationSpec } from '@backstage/plugin-catalog-common';
|
||||
|
||||
// A processor that reads from the fictional System-X
|
||||
export class SystemXReaderProcessor implements CatalogProcessor {
|
||||
constructor(private readonly reader: UrlReader) {}
|
||||
|
||||
@@ -93,3 +93,18 @@ You can also further customize groups by passing in a `titleComponent` instead
|
||||
of a `title` which will be a component to use as the header instead of just the
|
||||
default `ContentHeader` with the `title` set as it's value.
|
||||
|
||||
|
||||
There is also an option to hide some templates.
|
||||
You can have several use cases for that:
|
||||
|
||||
- it's still in an experimental phase, so you can combine it with feature flagging for example
|
||||
- you don't want to make them accessible from template list, but only open it on some action with pre-filled data.
|
||||
- show different set of templates depends on target environment
|
||||
|
||||
```typescript jsx
|
||||
<ScaffolderPage
|
||||
templateFilter={entity =>
|
||||
entity?.metadata?.tags?.includes('experimental') ?? false
|
||||
}
|
||||
/>
|
||||
```
|
||||
|
||||
@@ -58,6 +58,10 @@ It shouldn't take too long, and you'll have a success screen!
|
||||
If it fails, you'll be able to click on each section to get the log from the
|
||||
step that failed which can be helpful in debugging.
|
||||
|
||||
You can also cancel the running process. Once you clicked on button "Cancel", the abort signal
|
||||
will be sent to a task and all next steps won't be executed. The current step will be cancelled
|
||||
only if it supports it.
|
||||
|
||||
|
||||
|
||||
## View Component in Catalog
|
||||
|
||||
@@ -52,33 +52,54 @@ And this API should be the exact same as the previous Router, so you should be a
|
||||
|
||||
```tsx
|
||||
<Route
|
||||
path="/create"
|
||||
element={
|
||||
{/* highlight-remove-next-line */}
|
||||
<ScaffolderPage
|
||||
{/* highlight-add-next-line */}
|
||||
<NextScaffolderPage
|
||||
groups={[
|
||||
{
|
||||
title: 'Recommended',
|
||||
filter: entity =>
|
||||
entity?.metadata?.tags?.includes('recommended') ?? false,
|
||||
},
|
||||
]}
|
||||
/>
|
||||
}
|
||||
>
|
||||
<ScaffolderFieldExtensions>
|
||||
<LowerCaseValuePickerFieldExtension />
|
||||
{/* ... other extensions */}
|
||||
</ScaffolderFieldExtensions>
|
||||
<ScaffolderLayouts>
|
||||
<TwoColumnLayout />
|
||||
{/* ... other layouts */}
|
||||
</ScaffolderLayouts>
|
||||
</Route>
|
||||
path="/create"
|
||||
element={
|
||||
{/* highlight-remove-next-line */}
|
||||
<ScaffolderPage
|
||||
{/* highlight-add-next-line */}
|
||||
<NextScaffolderPage
|
||||
groups={[
|
||||
{
|
||||
title: 'Recommended',
|
||||
filter: entity =>
|
||||
entity?.metadata?.tags?.includes('recommended') ?? false,
|
||||
},
|
||||
]}
|
||||
/>
|
||||
}
|
||||
>
|
||||
<ScaffolderFieldExtensions>
|
||||
<LowerCaseValuePickerFieldExtension />
|
||||
{/* ... other extensions */}
|
||||
</ScaffolderFieldExtensions>
|
||||
<ScaffolderLayouts>
|
||||
<TwoColumnLayout />
|
||||
{/* ... other layouts */}
|
||||
</ScaffolderLayouts>
|
||||
</Route>
|
||||
```
|
||||
|
||||
Optionally, you can choose to run the two side by side by using `FeatureFlags` in your `App.tsx` if you wish, but, we would also recommend duplicating any `CustomFieldExtensions` too as the new `CustomFieldExtensions` might not be compatible with the old form.
|
||||
|
||||
```tsx
|
||||
<FeatureFlagged with="scaffolder-next-preview">
|
||||
<Route path="/create" element={<NextScaffolderPage />}>
|
||||
<ScaffolderFieldExtensions>
|
||||
<DelayingComponentFieldExtension />
|
||||
</ScaffolderFieldExtensions>
|
||||
</Route>
|
||||
</FeatureFlagged>
|
||||
<FeatureFlagged without="scaffolder-next-preview">
|
||||
<Route path="/create" element={<ScaffolderPage />}>
|
||||
<ScaffolderFieldExtensions>
|
||||
<DelayingComponentFieldExtension />
|
||||
</ScaffolderFieldExtensions>
|
||||
</Route>
|
||||
</FeatureFlagged>
|
||||
```
|
||||
|
||||
You should then be able to enable the `scaffolder-next-preview` feature flag under `/settings/feature-flags` in Backstage.
|
||||
|
||||
### Make the required changes to your `CustomFieldExtensions`
|
||||
|
||||
There's differently named function for creating field extensions part of the `/alpha` exports as these are the ones that can contain breaking changes because of the breaking changes that have been applied in `react-jsonschema-form`.
|
||||
@@ -197,9 +218,9 @@ You will need to change the import for `FieldValidation` to point at the new `re
|
||||
|
||||
```ts
|
||||
/* highlight-remove-next-line */
|
||||
- import { FieldValidation } from '@rjsf/core';
|
||||
import { FieldValidation } from '@rjsf/core';
|
||||
/* highlight-add-next-line */
|
||||
+ import { FieldValidation } from '@rjsf/utils;
|
||||
import { FieldValidation } from '@rjsf/utils;
|
||||
import { KubernetesValidatorFunctions } from '@backstage/catalog-model';
|
||||
|
||||
export const entityNamePickerValidation = (
|
||||
|
||||
@@ -71,7 +71,7 @@ You can also choose to define your custom action using JSON schema instead of `z
|
||||
|
||||
```ts title="With JSON Schema"
|
||||
import { createTemplateAction } from '@backstage/plugin-scaffolder-node';
|
||||
import fs from 'fs-extra';
|
||||
import { writeFile } from 'fs';
|
||||
|
||||
export const createNewFileAction = () => {
|
||||
return createTemplateAction<{ contents: string; filename: string }>({
|
||||
@@ -95,9 +95,12 @@ export const createNewFileAction = () => {
|
||||
},
|
||||
},
|
||||
async handler(ctx) {
|
||||
await fs.outputFile(
|
||||
const { signal } = ctx;
|
||||
await writeFile(
|
||||
`${ctx.workspacePath}/${ctx.input.filename}`,
|
||||
ctx.input.contents,
|
||||
{ signal },
|
||||
_ => {},
|
||||
);
|
||||
},
|
||||
});
|
||||
|
||||
@@ -472,6 +472,20 @@ owner:
|
||||
kind: [Group, User]
|
||||
```
|
||||
|
||||
#### `catalogFilter`
|
||||
|
||||
The `catalogFilter` allow you to filter the list entities using any of the [catalog api filters](https://backstage.io/docs/features/software-catalog/software-catalog-api#filtering):
|
||||
|
||||
For example, if you want to show users in the `default` namespace, and groups with the `github.com/team-slug` annotation, you can do the following:
|
||||
|
||||
```yaml
|
||||
catalogFilter:
|
||||
- kind: [User]
|
||||
metadata.namespace: default
|
||||
- kind: [Group]
|
||||
metadata.annotations.github.com/team-slug: { exists: true }
|
||||
```
|
||||
|
||||
## `spec.steps` - `Action[]`
|
||||
|
||||
The `steps` is an array of the things that you want to happen part of this
|
||||
|
||||
@@ -200,6 +200,15 @@ Options:
|
||||
-h, --help display help for command
|
||||
```
|
||||
|
||||
#### Publishing from behind a proxy
|
||||
|
||||
For users attempting to publish TechDocs content behind a proxy, the TechDocs CLI leverages `global-agent` to navigate the proxy to successfully connect to that location. To enable `global-agent`, the following variables need to be set prior to running the techdocs-cli command:
|
||||
|
||||
```bash
|
||||
export GLOBAL_AGENT_HTTPS_PROXY=${HTTP_PROXY}
|
||||
export GLOBAL_AGENT_NO_PROXY=${NO_PROXY}
|
||||
```
|
||||
|
||||
### Migrate content for case-insensitive access
|
||||
|
||||
Prior to the beta version of TechDocs (`v[0.11.0]`), TechDocs were stored in
|
||||
|
||||
@@ -21,6 +21,7 @@ catalog:
|
||||
gitlab:
|
||||
yourProviderId:
|
||||
host: gitlab-host # Identifies one of the hosts set up in the integrations
|
||||
branch: main # Optional. Used to discover on a specific branch
|
||||
fallbackBranch: main # Optional. Fallback to be used if there is no default branch configured at the Gitlab repository. It is only used, if `branch` is undefined. Uses `master` as default
|
||||
group: example-group # Optional. Group and subgroup (if needed) to look for repositories. If not present the whole instance will be scanned
|
||||
entityFilename: catalog-info.yaml # Optional. Defaults to `catalog-info.yaml`
|
||||
|
||||
@@ -2,15 +2,14 @@
|
||||
id: org
|
||||
title: GitLab Organizational Data
|
||||
sidebar_label: Org Data
|
||||
description: Importing users and groups from a GitLab organization into Backstage
|
||||
description: Importing users and groups from GitLab into Backstage
|
||||
---
|
||||
|
||||
The Backstage catalog can be set up to ingest organizational data - users and
|
||||
teams - directly from an organization in GitLab. The result
|
||||
is a hierarchy of
|
||||
The Backstage catalog can be set up to ingest organizational data -- users and
|
||||
groups -- directly from GitLab. The result is a hierarchy of
|
||||
[`User`](../../features/software-catalog/descriptor-format.md#kind-user) and
|
||||
[`Group`](../../features/software-catalog/descriptor-format.md#kind-group) kind
|
||||
entities that mirror your org setup.
|
||||
[`Group`](../../features/software-catalog/descriptor-format.md#kind-group)
|
||||
entities that mirrors your org setup.
|
||||
|
||||
```yaml
|
||||
integrations:
|
||||
@@ -19,10 +18,11 @@ integrations:
|
||||
token: ${GITLAB_TOKEN}
|
||||
```
|
||||
|
||||
This will query all users and groups from your gitlab installation. Depending on the size
|
||||
of the Gitlab Instance, this can take some time and resources.
|
||||
This will query all users and groups from your GitLab instance. Depending on the
|
||||
amount of data, this can take significant time and resources.
|
||||
|
||||
The token that is used for the Organization Integration, has to be an Admin Personal Access Token (PAT).
|
||||
The token used must have the `read_api` scope, and the Users and Groups fetched
|
||||
will be those visible to the account which provisioned the token.
|
||||
|
||||
```yaml
|
||||
catalog:
|
||||
@@ -35,6 +35,7 @@ catalog:
|
||||
groupPattern: '[\s\S]*' # Optional. Filters found groups based on provided pattern. Defaults to `[\s\S]*`, which means to not filter anything
|
||||
```
|
||||
|
||||
When the `group` parameter is provided, the corresponding path prefix will be stripped out from each matching group
|
||||
when computing the unique entity name. e.g. If `group` is `org/teams`, the name for `org/teams/avengers/gotg` will
|
||||
be `avengers-gotg`.
|
||||
When the `group` parameter is provided, the corresponding path prefix will be
|
||||
stripped out from each matching group when computing the unique entity name.
|
||||
e.g. If `group` is `org/teams`, the name for `org/teams/avengers/gotg` will be
|
||||
`avengers-gotg`.
|
||||
|
||||
@@ -505,6 +505,7 @@ of all supported file extensions:
|
||||
| `.jpg` | URL Path | Image |
|
||||
| `.png` | URL Path | Image |
|
||||
| `.svg` | URL Path | Image |
|
||||
| `.md` | URL Path | Markdown File |
|
||||
| `.icon.svg` | React Component | SVG converted into a [MUI SvgIcon](https://mui.com/components/icons/#svgicon) |
|
||||
|
||||
## Jest Configuration
|
||||
|
||||
@@ -73,7 +73,7 @@ Build packages in the project, excluding bundled app and backend packages.
|
||||
|
||||
Options:
|
||||
--all Build all packages, including bundled app and backend packages.
|
||||
--since <ref> Only build packages and their dev dependents that changed since the specified ref
|
||||
--since <ref> Only build packages and their dev dependents that changed since the specified ref
|
||||
```
|
||||
|
||||
## repo lint
|
||||
@@ -86,8 +86,8 @@ Usage: backstage-cli repo lint [options]
|
||||
Lint all packages in the project
|
||||
|
||||
Options:
|
||||
--format <format> Lint report output format (default: "eslint-formatter-friendly")
|
||||
--since <ref> Only lint packages that changed since the specified ref
|
||||
--format <format> Lint report output format (default: "eslint-formatter-friendly")
|
||||
--since <ref> Only lint packages that changed since the specified ref
|
||||
--fix Attempt to automatically fix violations
|
||||
```
|
||||
|
||||
@@ -101,8 +101,8 @@ Usage: backstage-cli package start [options]
|
||||
Start a package for local development
|
||||
|
||||
Options:
|
||||
--config <path> Config files to load instead of app-config.yaml (default: [])
|
||||
--role <name> Run the command with an explicit package role
|
||||
--config <path> Config files to load instead of app-config.yaml (default: [])
|
||||
--role <name> Run the command with an explicit package role
|
||||
--check Enable type checking and linting if available
|
||||
--inspect Enable debugger in Node.js environments
|
||||
--inspect-brk Enable debugger in Node.js environments, breaking before code starts
|
||||
@@ -118,11 +118,11 @@ Usage: backstage-cli package build [options]
|
||||
Build a package for production deployment or publishing
|
||||
|
||||
Options:
|
||||
--role <name> Run the command with an explicit package role
|
||||
--role <name> Run the command with an explicit package role
|
||||
--minify Minify the generated code. Does not apply to app or backend packages.
|
||||
--skip-build-dependencies Skip the automatic building of local dependencies. Applies to backend packages only.
|
||||
--stats If bundle stats are available, write them to the output directory. Applies to app packages only.
|
||||
--config <path> Config files to load instead of app-config.yaml. Applies to app packages only. (default: [])
|
||||
--config <path> Config files to load instead of app-config.yaml. Applies to app packages only. (default: [])
|
||||
```
|
||||
|
||||
## package lint
|
||||
@@ -138,7 +138,7 @@ Usage: backstage-cli package lint [options]
|
||||
Lint a package
|
||||
|
||||
Options:
|
||||
--format <format> Lint report output format (default: "eslint-formatter-friendly")
|
||||
--format <format> Lint report output format (default: "eslint-formatter-friendly")
|
||||
--fix Attempt to automatically fix violations
|
||||
```
|
||||
|
||||
@@ -227,10 +227,10 @@ that owns the app repo. For example you may have it set up like this:
|
||||
Usage: backstage-cli create [options]
|
||||
|
||||
Options:
|
||||
--select <name> Select the thing you want to be creating upfront
|
||||
--option <name>=<value> Pre-fill options for the creation process (default: [])
|
||||
--scope <scope> The scope to use for new packages
|
||||
--npm-registry <URL> The package registry to use for new packages
|
||||
--select <name> Select the thing you want to be creating upfront
|
||||
--option <name>=<value> Pre-fill options for the creation process (default: [])
|
||||
--scope <scope> The scope to use for new packages
|
||||
--npm-registry <URL> The package registry to use for new packages
|
||||
--no-private Do not mark new packages as private
|
||||
-h, --help display help for command
|
||||
```
|
||||
@@ -248,7 +248,7 @@ Usage: backstage-cli config:docs [options]
|
||||
Browse the configuration reference documentation
|
||||
|
||||
Options:
|
||||
--package <name> Only include the schema that applies to the given package
|
||||
--package <name> Only include the schema that applies to the given package
|
||||
-h, --help display help for command
|
||||
```
|
||||
|
||||
@@ -268,12 +268,12 @@ yarn backstage-cli config:print --frontend --package my-app
|
||||
Usage: backstage-cli config:print [options]
|
||||
|
||||
Options:
|
||||
--package <name> Only load config schema that applies to the given package
|
||||
--package <name> Only load config schema that applies to the given package
|
||||
--lax Do not require environment variables to be set
|
||||
--frontend Print only the frontend configuration
|
||||
--with-secrets Include secrets in the printed configuration
|
||||
--format <format> Format to print the configuration in, either json or yaml [yaml]
|
||||
--config <path> Config files to load instead of app-config.yaml (default: [])
|
||||
--format <format> Format to print the configuration in, either json or yaml [yaml]
|
||||
--config <path> Config files to load instead of app-config.yaml (default: [])
|
||||
-h, --help display help for command
|
||||
```
|
||||
|
||||
@@ -287,11 +287,11 @@ local packages in the repo.
|
||||
Usage: backstage-cli config:check [options]
|
||||
|
||||
Options:
|
||||
--package <name> Only load config schema that applies to the given package
|
||||
--package <name> Only load config schema that applies to the given package
|
||||
--lax Do not require environment variables to be set
|
||||
--frontend Only validate the frontend configuration
|
||||
--deprecated List all deprecated configuration settings
|
||||
--config <path> Config files to load instead of app-config.yaml (default: [])
|
||||
--config <path> Config files to load instead of app-config.yaml (default: [])
|
||||
-h, --help display help for command
|
||||
```
|
||||
|
||||
@@ -309,8 +309,8 @@ Usage: backstage-cli config:schema [options]
|
||||
Print configuration schema
|
||||
|
||||
Options:
|
||||
--package <name> Only output config schema that applies to the given package
|
||||
--format <format> Format to print the schema in, either json or yaml [yaml]
|
||||
--package <name> Only output config schema that applies to the given package
|
||||
--format <format> Format to print the schema in, either json or yaml [yaml]
|
||||
-h, --help display help for command
|
||||
```
|
||||
|
||||
@@ -325,8 +325,8 @@ Usage: backstage-cli versions:bump [options]
|
||||
|
||||
Options:
|
||||
-h, --help display help for command
|
||||
--pattern <glob> Override glob for matching packages to upgrade
|
||||
--release <version|next|main> Bump to a specific Backstage release line or version (default: "main")
|
||||
--pattern <glob> Override glob for matching packages to upgrade
|
||||
--release <version|next|main> Bump to a specific Backstage release line or version (default: "main")
|
||||
```
|
||||
|
||||
## versions:check
|
||||
|
||||
@@ -91,7 +91,7 @@ This enables decisions based on characteristics of the resource, but it's import
|
||||
Install the missing module:
|
||||
|
||||
```bash
|
||||
$ yarn workspace @internal/plugin-todo-list-backend add @backstage/plugin-permission-node zod
|
||||
$ yarn workspace @internal/plugin-todo-list-backend add @backstage/plugin-permission-node zod@~3.18.0
|
||||
```
|
||||
|
||||
Create a new `plugins/todo-list-backend/src/service/rules.ts` file and append the following code:
|
||||
|
||||
@@ -480,7 +480,7 @@ function isKind(kind: string) {
|
||||
```
|
||||
|
||||
The `@backstage/catalog` plugin provides a couple of built-in conditions,
|
||||
`isKind`, `isComponentType`, and `isNamespace`.
|
||||
`isKind`, `isComponentType`, `isResourceType`, `isEntityWith`, and `isNamespace`.
|
||||
|
||||
In addition to the `EntitySwitch` component, the catalog plugin also exports a
|
||||
new `EntityLayout` component. It is a tweaked version and replacement for the
|
||||
|
||||
@@ -142,7 +142,7 @@ export class FaqCollatorFactory implements DocumentCollatorFactory {
|
||||
|
||||
To verify your implementation works as expected make sure to add tests for it. For your convenience, there is the [`TestPipeline`](https://backstage.io/docs/reference/plugin-search-backend-node.testpipeline) utility that emulates a pipeline into which you can integrate your custom collator.
|
||||
|
||||
Look at [DefaultTechDocsCollatorFactory test](https://github.com/backstage/backstage/blob/master/plugins/techdocs-backend/src/search/DefaultTechDocsCollatorFactory.test.ts), for an example.
|
||||
Look at [DefaultTechDocsCollatorFactory test](https://github.com/backstage/backstage/blob/de294ce5c410c9eb56da6870a1fab795268f60e3/plugins/techdocs-backend/src/search/DefaultTechDocsCollatorFactory.test.ts), for an example.
|
||||
|
||||
#### 6. Make your plugins collator discoverable for others
|
||||
|
||||
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
id: v1.12.0
|
||||
title: v1.12.0
|
||||
description: Backstage Release v1.12.0
|
||||
---
|
||||
|
||||
These are the release notes for the v1.12.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
|
||||
|
||||
This release mostly contains a bunch of smaller additions and bug fixes, but on top of that, there’s also some quality of life improvements and features as listed below. Enjoy!
|
||||
|
||||
### Using `zod` for action definitions
|
||||
|
||||
As a convenience, it is now possible to define your action inputs and outputs as `zod` schemas. This tends to be more convenient than writing JSON schema by hand, and gives you instant type feedback in your editor.
|
||||
|
||||
Added by [@zcason](https://github.com/zcason) in [#15561](https://github.com/backstage/backstage/pull/15561)
|
||||
|
||||
### Reading paginated data from the catalog
|
||||
|
||||
The catalog has a new backend endpoint and corresponding client method, for fetching entities with proper cursor based pagination and server side filtering and ordering. This will be used to target performance hot-spots in the frontend and elsewhere.
|
||||
|
||||
Added by [@vinzscam](https://github.com/vinzscam) in [#12246](https://github.com/backstage/backstage/pull/12246)
|
||||
|
||||
### Renamed backend system related plugin exports
|
||||
|
||||
As we settle the new backend system bit by bit, we have renamed a number of exports from individual plugins, to match the new [recommended naming patterns](https://backstage.io/docs/backend-system/architecture/naming-patterns). If you are already leveraging the new backend system, you may find that you need to update some imports. For example, `githubEntityProviderCatalogModule` was renamed to `catalogModuleGithubEntityProvider`. These were considered non-breaking since they are still in alpha. More details can be found in [#16760](https://github.com/backstage/backstage/pull/16760) and [#16764](https://github.com/backstage/backstage/pull/16764).
|
||||
|
||||
### New plugin: `catalog-backend` `puppetdb` module
|
||||
|
||||
Added a `catalogModulePuppetDbEntityProvider` alpha export for the new backend system. Contributed by [@tdabasinskas](https://github.com/tdabasinskas) in [#16184](https://github.com/backstage/backstage/pull/16184)
|
||||
|
||||
### New plugin: Octopus deploy
|
||||
|
||||
[Octopus](https://octopus.com) deployment plugin. Contributed by [@jmezach](https://github.com/jmezach) in [#16353](https://github.com/backstage/backstage/pull/16353)
|
||||
|
||||
### New plugin: StackStorm
|
||||
|
||||
Integration with [StackStorm](https://stackstorm.com). Contributed by [@pamelin](https://github.com/pamelin) in [#16152](https://github.com/backstage/backstage/pull/16152)
|
||||
|
||||
## 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.12.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.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1 +1,2 @@
|
||||
build
|
||||
.docusaurus
|
||||
|
||||
+87
-71
@@ -1,6 +1,6 @@
|
||||
# Backstage Documentation
|
||||
|
||||
This folder holds the service and configuration that runs Backstage's documentation hosted at https://backstage.io.
|
||||
This folder holds the service and configuration that runs Backstage's documentation hosted at <https://backstage.io>.
|
||||
|
||||
It pulls content in from the [root `/docs`](../docs/) folder and builds it into the resulting HTML web site.
|
||||
|
||||
@@ -20,13 +20,13 @@ Testing the web site locally is a great way to see what final website will look
|
||||
|
||||
## Installation
|
||||
|
||||
```
|
||||
```bash
|
||||
$ yarn install
|
||||
```
|
||||
|
||||
## Local Development
|
||||
|
||||
```
|
||||
```bash
|
||||
$ yarn start
|
||||
```
|
||||
|
||||
@@ -34,7 +34,7 @@ This command starts a local development server and opens up a browser window. Mo
|
||||
|
||||
## Build
|
||||
|
||||
```
|
||||
```bash
|
||||
$ yarn build
|
||||
```
|
||||
|
||||
@@ -107,30 +107,30 @@ For more information about blog posts, click [here](https://docusaurus.io/docs/e
|
||||
|
||||
1. Create the doc as a new markdown file in `/docs`, example `docs/newly-created-doc.md`:
|
||||
|
||||
```md
|
||||
---
|
||||
id: newly-created-doc
|
||||
title: This Doc Needs To Be Edited
|
||||
---
|
||||
```md
|
||||
---
|
||||
id: newly-created-doc
|
||||
title: This Doc Needs To Be Edited
|
||||
---
|
||||
|
||||
My new content here..
|
||||
```
|
||||
My new content here..
|
||||
```
|
||||
|
||||
1. Refer to that doc's ID in an existing sidebar in `website/sidebars.json`:
|
||||
2. Refer to that doc's ID in an existing sidebar in `website/sidebars.json`:
|
||||
|
||||
```javascript
|
||||
// Add newly-created-doc to the Getting Started category of docs
|
||||
{
|
||||
"docs": {
|
||||
"Getting Started": [
|
||||
"quick-start",
|
||||
"newly-created-doc" // new doc here
|
||||
],
|
||||
...
|
||||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
```javascript
|
||||
// Add newly-created-doc to the Getting Started category of docs
|
||||
{
|
||||
"docs": {
|
||||
"Getting Started": [
|
||||
"quick-start",
|
||||
"newly-created-doc" // new doc here
|
||||
],
|
||||
...
|
||||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
For more information about adding new docs, click [here](https://docusaurus.io/docs/en/navigation)
|
||||
|
||||
@@ -138,30 +138,30 @@ For more information about adding new docs, click [here](https://docusaurus.io/d
|
||||
|
||||
1. Make sure there is a header link to your blog in `website/siteConfig.js`:
|
||||
|
||||
`website/siteConfig.js`
|
||||
`website/siteConfig.js`
|
||||
|
||||
```javascript
|
||||
headerLinks: [
|
||||
...
|
||||
{ blog: true, label: 'Blog' },
|
||||
...
|
||||
]
|
||||
```
|
||||
```javascript
|
||||
headerLinks: [
|
||||
...
|
||||
{ blog: true, label: 'Blog' },
|
||||
...
|
||||
]
|
||||
```
|
||||
|
||||
2. Create the blog post with the format `YYYY-MM-DD-My-Blog-Post-Title.md` in `website/blog`:
|
||||
|
||||
`website/blog/2018-05-21-New-Blog-Post.md`
|
||||
`website/blog/2018-05-21-New-Blog-Post.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
author: Frank Li
|
||||
authorURL: https://twitter.com/foobarbaz
|
||||
authorFBID: 503283835
|
||||
title: New Blog Post
|
||||
---
|
||||
```markdown
|
||||
---
|
||||
author: Frank Li
|
||||
authorURL: https://twitter.com/foobarbaz
|
||||
authorFBID: 503283835
|
||||
title: New Blog Post
|
||||
---
|
||||
|
||||
Lorem Ipsum...
|
||||
```
|
||||
Lorem Ipsum...
|
||||
```
|
||||
|
||||
For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog)
|
||||
|
||||
@@ -169,43 +169,44 @@ For more information about blog posts, click [here](https://docusaurus.io/docs/e
|
||||
|
||||
1. Add links to docs, custom pages or external links by editing the `headerLinks` field of `website/siteConfig.js`:
|
||||
|
||||
`website/siteConfig.js`
|
||||
`website/siteConfig.js`
|
||||
|
||||
```javascript
|
||||
{
|
||||
headerLinks: [
|
||||
...
|
||||
/* you can add docs */
|
||||
{ doc: 'my-examples', label: 'Examples' },
|
||||
/* you can add custom pages */
|
||||
{ page: 'help', label: 'Help' },
|
||||
/* you can add external links */
|
||||
{ href: 'https://github.com/facebook/docusaurus', label: 'GitHub' },
|
||||
...
|
||||
],
|
||||
...
|
||||
}
|
||||
```
|
||||
```javascript
|
||||
{
|
||||
headerLinks: [
|
||||
...
|
||||
/* you can add docs */
|
||||
{ doc: 'my-examples', label: 'Examples' },
|
||||
/* you can add custom pages */
|
||||
{ page: 'help', label: 'Help' },
|
||||
/* you can add external links */
|
||||
{ href: 'https://github.com/facebook/docusaurus', label: 'GitHub' },
|
||||
...
|
||||
],
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
For more information about the navigation bar, click [here](https://docusaurus.io/docs/en/navigation)
|
||||
|
||||
### Adding custom pages
|
||||
|
||||
1. Docusaurus uses React components to build pages. The components are saved as .js files in `website/pages/en`:
|
||||
1. If you want your page to show up in your navigation header, you will need to update `website/siteConfig.js` to add to the `headerLinks` element:
|
||||
|
||||
`website/siteConfig.js`
|
||||
2. If you want your page to show up in your navigation header, you will need to update `website/siteConfig.js` to add to the `headerLinks` element:
|
||||
|
||||
```javascript
|
||||
{
|
||||
headerLinks: [
|
||||
...
|
||||
{ page: 'my-new-custom-page', label: 'My New Custom Page' },
|
||||
...
|
||||
],
|
||||
...
|
||||
}
|
||||
```
|
||||
`website/siteConfig.js`
|
||||
|
||||
```javascript
|
||||
{
|
||||
headerLinks: [
|
||||
...
|
||||
{ page: 'my-new-custom-page', label: 'My New Custom Page' },
|
||||
...
|
||||
],
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Learn more about [Docusaurus custom pages](https://docusaurus.io/docs/en/custom-pages).
|
||||
|
||||
@@ -216,4 +217,19 @@ Full documentation can be found on the [Docusaurus website](https://docusaurus.i
|
||||
## Additional notes
|
||||
|
||||
- If you want to make images zoomable on click, add the `data-zoomable` attribute to your `img` element.
|
||||
|
||||
- In a docs or blog `.md` file, convert `` syntax to `<img data-zoomable src="/microsite/static/img/code.png" alt="This is image" />`
|
||||
|
||||
- Code block line highlighting uses [custom magic comments](https://docusaurus.io/docs/markdown-features/code-blocks#custom-magic-comments). Currently, we have the following magic comments:
|
||||
- Highlight line(s)
|
||||
- `highlight-next-line`
|
||||
- `highlight-start`
|
||||
- `highlight-end`
|
||||
- Add line(s)
|
||||
- `highlight-add-next-line`
|
||||
- `highlight-add-start`
|
||||
- `highlight-add-end`
|
||||
- Remove line(s)
|
||||
- `highlight-remove-next-line`
|
||||
- `highlight-remove-start`
|
||||
- `highlight-remove-end`
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: Backstage Turns Three!
|
||||
author: Ben Lambert
|
||||
authorURL: https://github.com/benjdlambert
|
||||
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-->
|
||||
|
||||
## They grow up so fast, don’t they?
|
||||
|
||||
Happy birthday, Backstage! Three years ago, Spotify released its homegrown developer portal into the wild after a small team collaborated on an internal Hack Week project. We’d had a lot of conversations with companies looking to build out something similar to what we’d been running for years, so our Hack Week sprint started as an experiment to see if the Backstage core plugins could be valuable in open source.
|
||||
|
||||
It's cliché at this point — because we’ve said it a million times — but no one could have predicted what came next.
|
||||
|
||||
In three short years, Backstage has grown to a Cloud Native Computing Foundation Incubating project, with more than 900 adopters and 1000+ contributors worldwide. Companies like CVS Health, Siemens, LinkedIn, REI, Vodafone, and Lego are building out their own developer portals from the Backstage framework and bringing their learnings to the project.
|
||||
|
||||
A few more stats we love to see (mainly coming from the [project repo](https://github.com/backstage/backstage)):
|
||||
|
||||
- 3k+ project forks
|
||||
- 38k+ commits
|
||||
- 12k+ PRs
|
||||
- 15k+ total contributions
|
||||
- 21k+ stars on GitHub
|
||||
- 9k+ Discord members
|
||||
- 100+ open source plugins in the [plugin marketplace](https://backstage.io/plugins)
|
||||
|
||||
But, without a doubt, the best thing about the Backstage project is the people in this community. People who are curious, collaborative, and excited to share knowledge. People who’ll sift through Discord at all hours to answer questions and support one another. People who come from all over the world but share a common trait: being passionate about enabling developers to do their best work.
|
||||
|
||||
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>
|
||||
|
||||
## The growing pains are real
|
||||
|
||||
But it's not all sunshine and roses in Backstage-land. If Year 1 was about getting this community going and Year 2 was focused on maturing the platform, then Year 3 needs to address some of the inevitable growing pains a project undergoes as it gains ground.
|
||||
|
||||
We hear two things pretty consistently from the community:
|
||||
|
||||
- **Backstage is a steep learning curve:** Over the past three years, the project has grown in scope and breadth which can translate to complexity. This is especially true for newcomers looking to get their arms wrapped around the key concepts.
|
||||
- **Backstage has barriers to adoption:** Backstage adopters tell us driving widespread adoption of their developer portal remains the biggest challenge they face. Adoption barriers can be technical but are often cultural.
|
||||
|
||||
The maintainers and some of our most involved community members are actively tackling how we can make the Backstage onboarding process easier for contributors. There are also lots of ways the project could better support adopters on that journey and make adoption faster and smoother.
|
||||
|
||||
We’re looking at everything from cleaning up documentation to opinionated catalog ingestors being discussed in both the Catalog and Adoption monthly SIGs (running meeting notes [here](https://docs.google.com/document/d/1xg57CDfX2R5jTGbbWANzifm2szEb664kuTwfEEvKgZU/) and [here](https://docs.google.com/document/d/1zeYSzXYgh897bxPQmwy2btOwCFlEjlUDLf00riySLRc)). A few priorities that we’ve already mapped out:
|
||||
|
||||
- Make it easier to install, customize, and maintain Backstage
|
||||
- Provide Golden Paths for adoption
|
||||
- Improve the experience and the content on [backstage.io](https://backstage.io/docs/overview/what-is-backstage)
|
||||
|
||||
Because there are now so many mature adopters — Spotify included — there’s so much knowledge on how to create a roadmap for adoption and use cases, how to roll out your developer portal to your teams and drive inner source contributions, how to measure and attribute developer productivity gains, etc.
|
||||
|
||||
Our goal is to tap into the knowledge those adopters have gained and create more tangible resources for the entire community. But we can’t do it without help. And that’s where you come in!
|
||||
|
||||
## Getting (more) involved
|
||||
|
||||
We’re very grateful for the Backstage ride-or-dies: the contributors who show up to every community session, attend every SIG, and are always ready to jump in on any PR or issue.
|
||||
|
||||
But one of the areas where we think the project could greatly improve (and better address some of the growing pains I mentioned above!) is more active contribution — both the total number of people contributing and what they’re contributing.
|
||||
|
||||
We’ve already shared a bit on this but the maintainer team is starting to address this challenge by proposing the following three initiatives:
|
||||
|
||||
- Introduce more steps in between first-time contributor and maintainer in the form of a contributor ladder (loosely based on the [CNCF Project Template](https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md)).
|
||||
- Change the ownership model, for example, divide the project up into several project areas, each covering particular parts of the project.
|
||||
- Introduce a new process for large contributions in the form of Backstage Enhancement Proposals (BEPs).
|
||||
|
||||
These two RFCs on [Updated Backstage Governance](https://github.com/backstage/backstage/issues/15317) and [Backstage Enhancement Proposals](https://github.com/backstage/backstage/issues/15318) remain open so feel free to read and join the discussion! Watch this space as we’ll share more on the go-forward governance and BEPs plan soon.
|
||||
|
||||
But if you’re brand-new and just looking to get your feet wet, we’ve also [compiled some small steps](https://backstage.io/docs/getting-started/getting-involved/) you can take to get involved:
|
||||
|
||||
- Report (or squash) bugs: Look through the GitHub issues for [bugs](https://github.com/backstage/backstage/labels/bug), [good first issues](https://github.com/backstage/backstage/labels/good%20first%20issue) or [help wanted](https://github.com/backstage/backstage/labels/help%20wanted)
|
||||
- Build or suggest a plugin: The Backstage project grows with every new plugin that gets added
|
||||
- Add non-code contributions: We welcome things that help the community at large, but may not fit into the scope of the core project
|
||||
- Write documentation or improve the website: The current documentation and project site are pretty limited. Better content helps a lot of those growing pains.
|
||||
- Contribute to Storybook: Help us [create new components](https://github.com/backstage/backstage/labels/help%20wanted) or improve stories for the existing ones
|
||||
- Submit feedback: The best way to send feedback is to file [an issue](https://github.com/backstage/backstage/issues) with as much detail as possible
|
||||
- Add your company to ADOPTERS: Adding your company to [ADOPTERS](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) really helps the project, you can do this by filling out this [adopter form](https://form.typeform.com/to/zcOaKikB)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: backstage-plugin-api-linter
|
||||
title: API Linter
|
||||
author: Zalando
|
||||
authorUrl: https://github.com/zalando
|
||||
category: Linting
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Cloudsmith
|
||||
author: Roadie
|
||||
author: roadie.io
|
||||
authorUrl: https://roadie.io
|
||||
category: CI/CD
|
||||
description: Show Cloudsmith Repository stats, Quota, Audit logs and Security scans for specific repositories.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Github Pull Requests Board
|
||||
title: GitHub Pull Requests Board
|
||||
author: DAZN
|
||||
authorUrl: https://engineering.dazn.com
|
||||
category: Source Control Mgmt
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
title: Microsoft Calendar
|
||||
author: StatusNeo
|
||||
authorUrl: https://statusneo.com/
|
||||
category: Productivity
|
||||
description: |
|
||||
The plugin integrates with your Microsoft Calendar.
|
||||
It displays all your calendars and events in it.
|
||||
documentation: https://github.com/backstage/backstage/tree/master/plugins/microsoft-calendar
|
||||
iconUrl: /img/outlook-statusneo.png
|
||||
npmPackageName: '@backstage/plugin-microsoft-calendar'
|
||||
tags:
|
||||
- Microsoft
|
||||
- calendar
|
||||
- Management
|
||||
addedDate: '2023-03-15'
|
||||
@@ -1,9 +1,9 @@
|
||||
---
|
||||
title: Scaffolder AWS cli actions
|
||||
title: Scaffolder AWS CLI actions
|
||||
author: roadie.io
|
||||
authorUrl: https://roadie.io/?utm_source=backstage.io&utm_medium=marketplace&utm_campaign=scaffolder-aws
|
||||
category: Scaffolder
|
||||
description: Here you can find some AWS cli actions
|
||||
description: Scaffolder actions you can trigger for Amazon Web Services.
|
||||
documentation: https://github.com/RoadieHQ/roadie-backstage-plugins/blob/main/plugins/scaffolder-actions/scaffolder-backend-module-aws/README.md
|
||||
iconUrl: https://upload.wikimedia.org/wikipedia/commons/9/93/Amazon_Web_Services_Logo.svg
|
||||
npmPackageName: '@roadiehq/scaffolder-backend-module-aws'
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
title: Statusneo GitHub Plugin
|
||||
author: Statusneo
|
||||
authorUrl: https://statusneo.com/
|
||||
category: GitHub
|
||||
description: Provides status cards GitHub pull requests and GitHub actions.
|
||||
documentation: https://github.com/StatusNeo/backstage-plugin-github
|
||||
iconUrl: /img/github-statusneo.png
|
||||
npmPackageName: '@statusneo/backstage-plugin-github'
|
||||
tags:
|
||||
- GitHub
|
||||
- Monitoring
|
||||
- Productivity
|
||||
addedDate: '2023-02-15'
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Vault
|
||||
author: Spread Group
|
||||
authorUrl: https://github.com/ivangonzalezacuna
|
||||
category: Vault
|
||||
category: Security
|
||||
description: Visualize a list of the secrets stored in your HashiCorp Vault instance.
|
||||
documentation: https://github.com/backstage/backstage/tree/master/plugins/vault
|
||||
iconUrl: /img/vault.png
|
||||
|
||||
@@ -16,6 +16,11 @@
|
||||
|
||||
// @ts-check
|
||||
|
||||
/** @type{import('prism-react-renderer').PrismTheme} **/
|
||||
// @ts-ignore
|
||||
const prismTheme = require('prism-react-renderer/themes/vsDark');
|
||||
prismTheme.plain.backgroundColor = '#232323';
|
||||
|
||||
/** @type {import('@docusaurus/types').Config} */
|
||||
module.exports = {
|
||||
title: 'Backstage Software Catalog and Developer Platform',
|
||||
@@ -55,7 +60,7 @@ module.exports = {
|
||||
path: 'blog',
|
||||
},
|
||||
theme: {
|
||||
customCss: 'src/css/customTheme.css',
|
||||
customCss: 'src/theme/customTheme.scss',
|
||||
},
|
||||
gtag: {
|
||||
trackingID: 'G-KSEVGGNCJW',
|
||||
@@ -158,7 +163,7 @@ module.exports = {
|
||||
position: 'left',
|
||||
},
|
||||
{
|
||||
to: 'docs/releases/v1.11.0',
|
||||
to: 'docs/releases/v1.12.0',
|
||||
label: 'Releases',
|
||||
position: 'left',
|
||||
},
|
||||
@@ -266,10 +271,11 @@ module.exports = {
|
||||
searchParameters: {},
|
||||
},
|
||||
prism: {
|
||||
theme: prismTheme,
|
||||
magicComments: [
|
||||
// Extend the default highlight class name
|
||||
{
|
||||
className: 'theme-code-block-highlighted-line',
|
||||
className: 'code-block-highlight-line',
|
||||
line: 'highlight-next-line',
|
||||
block: { start: 'highlight-start', end: 'highlight-end' },
|
||||
},
|
||||
|
||||
@@ -35,6 +35,7 @@
|
||||
"@swc/core": "^1.3.36",
|
||||
"clsx": "^1.1.1",
|
||||
"docusaurus-plugin-sass": "^0.2.3",
|
||||
"prism-react-renderer": "^1.3.5",
|
||||
"react": "^17.0.2",
|
||||
"react-dom": "^17.0.2",
|
||||
"sass": "^1.57.1",
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
{
|
||||
"releases": {
|
||||
"Release Notes": [
|
||||
"releases/v1.12.0",
|
||||
"releases/v1.11.0",
|
||||
"releases/v1.10.0",
|
||||
"releases/v1.9.0",
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user