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

Merge remote-tracking branch 'upstream/master' into 6239-responsive-sidebar

Browse Source
This commit is contained in:
Philipp Hugenroth
2021-06-29 17:17:56 +02:00
parent a446bffdb2 dfb9c73321
commit 50dc04bf41
779 changed files with 4521 additions and 34960 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.changeset/blue-planes-fail.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-catalog': patch
---
improve the wrapping behavior of long entity links
.changeset/breezy-books-matter.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-search': patch
---
Fix empty state not being displayed on missing results.
.changeset/config.json
+4 -1
View File
@@ -6,5 +6,8 @@
"access": "public",
"baseBranch": "master",
"updateInternalDependencies": "patch",
"ignore": []
"ignore": [],
"___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
"onlyUpdatePeerDependentsWhenOutOfRange": true
}
}
.changeset/cuddly-donuts-whisper.md
-54
View File
@@ -1,54 +0,0 @@
---
'@backstage/plugin-explore': patch
---
Refactors the explore plugin to be more customizable. This includes the following non-breaking changes:
- Introduce new `ExploreLayout` page which can be used to create a custom `ExplorePage`
- Refactor `ExplorePage` to use a new `ExploreLayout` component
- Exports existing `DomainExplorerContent`, `GroupsExplorerContent`, & `ToolExplorerContent` components
- Allows `title` props to be customized
Create a custom explore page in `packages/app/src/components/explore/ExplorePage.tsx`.
```tsx
import {
DomainExplorerContent,
ExploreLayout,
} from '@backstage/plugin-explore';
import React from 'react';
import { InnserSourceExplorerContent } from './InnserSourceExplorerContent';
export const ExplorePage = () => {
return (
<ExploreLayout
title="Explore the ACME corp ecosystem"
subtitle="Browse our ecosystem"
>
<ExploreLayout.Route path="domains" title="Domains">
<DomainExplorerContent />
</ExploreLayout.Route>
<ExploreLayout.Route path="inner-source" title="InnerSource">
<AcmeInnserSourceExplorerContent />
</ExploreLayout.Route>
</ExploreLayout>
);
};
export const explorePage = <ExplorePage />;
```
Now register the new explore page in `packages/app/src/App.tsx`.
```diff
+ import { explorePage } from './components/explore/ExplorePage';
const routes = (
<FlatRoutes>
- <Route path="/explore" element={<ExplorePage />} />
+ <Route path="/explore" element={<ExplorePage />}>
+ {explorePage}
+ </Route>
</FlatRoutes>
);
```
.changeset/curly-eggs-destroy.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
Updated dependencies
.changeset/early-buckets-type.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder': patch
---
Upgrade `rjsf` to 3.0.0.
.changeset/fair-dolphins-relate.md
+7
View File
@@ -0,0 +1,7 @@
---
'@backstage/plugin-catalog-backend-module-msgraph': minor
---
Handle error gracefully if failure occurs while loading photos using Microsoft Graph API.
This includes a breaking change: you now have to pass the `options` object to `readMicrosoftGraphUsers` and `readMicrosoftGraphOrg`.
.changeset/fair-knives-relax.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/core-app-api': patch
---
Introducing new UnhandledErrorForwarder installed by default. For catching unhandled promise rejections, you can override the API to align with general error handling.
.changeset/few-windows-whisper.md
-8
View File
@@ -1,8 +0,0 @@
---
'@backstage/core-app-api': patch
'@backstage/core-plugin-api': patch
'@backstage/plugin-catalog': patch
'@backstage/plugin-scaffolder': patch
---
Adding `FeatureFlag` component and treating `FeatureFlags` as first class citizens to composability API
.changeset/five-baboons-explain.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/dev-utils': minor
---
Removed support for deprecated registered plugin routes. All routes now need to be added using `addPage` instead.
.changeset/forty-dodos-own.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/catalog-client': patch
---
Return entities sorted alphabetically by ref
.changeset/forty-students-brake.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-scaffolder-backend': patch
---
Fix `catalog:write` on windows systems
.changeset/friendly-bikes-double.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/cli': patch
---
updated plugin template to generate path equals plugin id for the root page
.changeset/fuzzy-bottles-greet.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/core-app-api': patch
---
Reintroduce export of `defaultConfigLoader`.
.changeset/gold-avocados-thank.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/backend-common': patch
---
Download archives as compressed tar files for GitLab to fix the `readTree` bug in TODO Plugin.
.changeset/good-jars-turn.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-search': patch
---
Use the `identityApi` to forward authorization headers to the `search-backend`
.changeset/great-ads-yawn.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-catalog': patch
---
Allow `defaultKind` from `CatalogTable.column.creatNameColumn` to be configurable
.changeset/grumpy-sloths-check.md
+6
View File
@@ -0,0 +1,6 @@
---
'@backstage/core-components': patch
'@backstage/plugin-catalog': patch
---
Fixed sizing of the System diagram when the rendered graph was wider than the container.
.changeset/heavy-numbers-refuse.md
-10
View File
@@ -1,10 +0,0 @@
---
'@backstage/plugin-api-docs': minor
'@backstage/plugin-cost-insights': minor
'@backstage/plugin-gcp-projects': minor
'@backstage/plugin-gitops-profiles': minor
'@backstage/plugin-newrelic': minor
'@backstage/plugin-welcome': minor
---
**BREAKING CHANGE** Remove deprecated route registrations, meaning that it is no longer enough to only import the plugin in the app and the exported page extension must be used instead.
.changeset/perfect-gifts-compete.md → .changeset/long-olives-cheer.md
+1 -1
View File
@@ -2,4 +2,4 @@
'@backstage/plugin-auth-backend': patch
---
Don't export the `defaultGoogleAuthProvider`
Unbreak `.well-known` OIDC routes
.changeset/loud-pets-hang.md
+6
View File
@@ -0,0 +1,6 @@
---
'@backstage/techdocs-common': patch
'@backstage/plugin-scaffolder-backend': patch
---
Use new utilities from `@backstage/backend-common` for safely resolving child paths
.changeset/many-penguins-clap.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli-common': patch
---
Add new `isChildPath` export
.changeset/metal-badgers-carry.md
-25
View File
@@ -1,25 +0,0 @@
---
'@backstage/plugin-catalog-backend': patch
'@backstage/plugin-catalog-backend-module-msgraph': patch
---
Move `MicrosoftGraphOrgReaderProcessor` from `@backstage/plugin-catalog-backend`
to `@backstage/plugin-catalog-backend-module-msgraph`.
The `MicrosoftGraphOrgReaderProcessor` isn't registered by default anymore, if
you want to continue using it you have to register it manually at the catalog
builder:
1. Add dependency to `@backstage/plugin-catalog-backend-module-msgraph` to the `package.json` of your backend.
2. Add the processor to the catalog builder:
```typescript
// packages/backend/src/plugins/catalog.ts
builder.addProcessor(
MicrosoftGraphOrgReaderProcessor.fromConfig(config, {
logger,
}),
);
```
For more configuration details, see the [README of the `@backstage/plugin-catalog-backend-module-msgraph` package](https://github.com/backstage/backstage/blob/master/plugins/catalog-backend-module-msgraph/README.md).
.changeset/metal-cycles-run.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-techdocs': patch
---
Fix the overlapping between the sidebar and the tabs navigation when enabled in mkdocs (features: navigation.tabs)
.changeset/nasty-crews-boil.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-cost-insights': patch
---
Replaced moment and dayjs with Luxon
.changeset/nasty-games-share.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
Update dependencies
.changeset/odd-humans-exercise.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/cli': patch
---
Make the `create-github-app` command disable webhooks by default.
.changeset/orange-news-sparkle.md
+46
View File
@@ -0,0 +1,46 @@
---
'@backstage/integration': patch
'@backstage/plugin-catalog-backend': patch
---
Support ingesting multiple GitHub organizations via a new `GithubMultiOrgReaderProcessor`.
This new processor handles namespacing created groups according to the org of the associated GitHub team to prevent potential name clashes between organizations. Be aware that this processor is considered alpha and may not be compatible with future org structures in the catalog.
NOTE: This processor only fully supports auth via GitHub Apps
To install this processor, import and add it as follows:
```typescript
// Typically in packages/backend/src/plugins/catalog.ts
import { GithubMultiOrgReaderProcessor } from '@backstage/plugin-catalog-backend';
// ...
export default async function createPlugin(env: PluginEnvironment) {
const builder = new CatalogBuilder(env);
builder.addProcessor(
GithubMultiOrgReaderProcessor.fromConfig(env.config, {
logger: env.logger,
}),
);
// ...
}
```
Configure in your `app-config.yaml` by pointing to your GitHub instance and optionally list which GitHub organizations you wish to import. You can also configure what namespace you want to set for teams from each org. If unspecified, the org name will be used as the namespace. If no organizations are listed, by default this processor will import from all organizations accessible by all configured GitHub Apps:
```yaml
catalog:
locations:
- type: github-multi-org
target: https://github.myorg.com
processors:
githubMultiOrg:
orgs:
- name: fooOrg
groupNamespace: foo
- name: barOrg
groupNamespace: bar
- name: awesomeOrg
- name: anotherOrg
```
.changeset/plenty-kings-shout.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/cli': patch
---
chore: bump `@typescript-eslint/eslint-plugin` from 4.26.0 to 4.27.0
.changeset/popular-rice-wonder.md
-8
View File
@@ -1,8 +0,0 @@
---
'@backstage/plugin-catalog': patch
'@backstage/plugin-catalog-backend': patch
'@backstage/plugin-scaffolder': patch
'@backstage/plugin-scaffolder-backend': patch
---
Moved installation instructions from the main [backstage.io](https://backstage.io) documentation to the package README file. These instructions are not generally needed, since the plugin comes installed by default with `npx @backstage/create-app`.
.changeset/purple-carpets-fold.md
+7
View File
@@ -0,0 +1,7 @@
---
'@backstage/techdocs-common': patch
'@backstage/plugin-register-component': patch
'@backstage/plugin-techdocs-backend': patch
---
Update "service catalog" references to "software catalog"
.changeset/red-apricots-perform.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/cli': patch
---
chore: bump `del` from 5.1.0 to 6.0.0
.changeset/rich-trees-chew.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/cli': patch
---
chore: bump `@spotify/eslint-config-typescript` from 9.0.0 to 10.0.0
.changeset/rude-pumpkins-hang.md
+32
View File
@@ -0,0 +1,32 @@
---
'@backstage/core-components': patch
---
Make `ErrorBoundary` display more helpful information about the error that
occurred.
The `slackChannel` (optional) prop can now be passed as an object on the form
`{ name: string; href?: string; }` in addition to the old string form. If you
are using the error boundary like
```tsx
<ErrorBoundary slackChannel="#support">
<InnerComponent>
</ErrorBoundary>
```
you may like to migrate it to
```tsx
const support = {
name: '#support',
href: 'https://slack.com/channels/your-channel',
};
<ErrorBoundary slackChannel={support}>
<InnerComponent>
</ErrorBoundary>
```
Also deprecated the prop `slackChannel` on `TabbedCard` and `InfoCard`, while
adding the prop `errorBoundaryProps` to replace it.
.changeset/search-tasty-crews-tie.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-search-backend-node': patch
---
Handle errors in collators and decorators and log them.
.changeset/seven-adults-act.md
-25
View File
@@ -1,25 +0,0 @@
---
'@backstage/plugin-auth-backend': patch
---
Adds support for custom sign-in resolvers and profile transformations for the
Google auth provider.
Adds an `ent` claim in Backstage tokens, with a list of
[entity references](https://backstage.io/docs/features/software-catalog/references)
related to your signed-in user's identities and groups across multiple systems.
Adds an optional `providerFactories` argument to the `createRouter` exported by
the `auth-backend` plugin.
Updates `BackstageIdentity` so that
- `idToken` is deprecated in favor of `token`
- An optional `entity` field is added which represents the entity that the user is represented by within Backstage.
More information:
- [The identity resolver documentation](https://backstage.io/docs/auth/identity-resolver)
explains the concepts and shows how to implement your own.
- The [From Identity to Ownership](https://github.com/backstage/backstage/issues/4089)
RFC contains details about how this affects ownership in the catalog
.changeset/short-numbers-carry.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-search-backend-node': patch
---
Fixed bug preventing searches with filter values containing `:` from returning results.
.changeset/silent-avocados-beam.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/cli': patch
---
Use new `isChildPath` export from `@backstage/cli-common`
.changeset/silent-ways-laugh.md
-6
View File
@@ -1,6 +0,0 @@
---
'@backstage/plugin-catalog-backend-module-msgraph': patch
---
Allow customizations of `MicrosoftGraphOrgReaderProcessor` by passing an
optional `groupTransformer`, `userTransformer`, and `organizationTransformer`.
.changeset/six-weeks-shop.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/backend-common': patch
---
Add new `isChildPath` and `resolveSafeChildPath` exports
.changeset/slow-jobs-doubt.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-github-actions': patch
---
Migrate from Moment to Luxon
.changeset/smart-insects-care.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-catalog': patch
---
Disambiguated titles of `EntityDependencyOfComponentsCard` and `EntityDependsOnComponentsCard`.
.changeset/sour-cherries-occur.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/catalog-client': patch
---
Don't crash if the entities response doesn't include the entities name and kind
.changeset/sour-donuts-tickle.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-catalog': patch
---
Adds an optional `actions` prop to `CatalogTable` and `CatalogPage` to support supplying custom actions for each entity row in the table. This uses the default actions if not provided.
.changeset/stupid-scissors-brake.md
-51
View File
@@ -1,51 +0,0 @@
---
'@backstage/catalog-model': patch
'@backstage/cli': patch
'@backstage/create-app': patch
'@backstage/dev-utils': patch
'@backstage/integration-react': patch
'@backstage/test-utils': patch
'@backstage/plugin-api-docs': patch
'@backstage/plugin-badges': patch
'@backstage/plugin-bitrise': patch
'@backstage/plugin-catalog': patch
'@backstage/plugin-catalog-import': patch
'@backstage/plugin-catalog-react': patch
'@backstage/plugin-circleci': patch
'@backstage/plugin-cloudbuild': patch
'@backstage/plugin-code-coverage': patch
'@backstage/plugin-config-schema': patch
'@backstage/plugin-cost-insights': patch
'@backstage/plugin-explore': patch
'@backstage/plugin-explore-react': patch
'@backstage/plugin-fossa': patch
'@backstage/plugin-gcp-projects': patch
'@backstage/plugin-git-release-manager': patch
'@backstage/plugin-github-actions': patch
'@backstage/plugin-github-deployments': patch
'@backstage/plugin-gitops-profiles': patch
'@backstage/plugin-graphiql': patch
'@backstage/plugin-ilert': patch
'@backstage/plugin-jenkins': patch
'@backstage/plugin-kafka': patch
'@backstage/plugin-kubernetes': patch
'@backstage/plugin-lighthouse': patch
'@backstage/plugin-newrelic': patch
'@backstage/plugin-org': patch
'@backstage/plugin-pagerduty': patch
'@backstage/plugin-register-component': patch
'@backstage/plugin-rollbar': patch
'@backstage/plugin-scaffolder': patch
'@backstage/plugin-search': patch
'@backstage/plugin-sentry': patch
'@backstage/plugin-shortcuts': patch
'@backstage/plugin-sonarqube': patch
'@backstage/plugin-splunk-on-call': patch
'@backstage/plugin-tech-radar': patch
'@backstage/plugin-techdocs': patch
'@backstage/plugin-todo': patch
'@backstage/plugin-user-settings': patch
'@backstage/plugin-welcome': patch
---
Migrated to use the new `@backstage/core-*` packages rather than `@backstage/core`.
.changeset/swift-fishes-taste.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-backend': patch
---
Ensure that emitted relations are deduplicated
.changeset/techdocs-cool-rivers-suffer.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-techdocs': patch
---
Refactor the implicit logic from `<Reader />` into an explicit state machine. This resolves some state synchronization issues when content is refreshed or rebuilt in the backend.
.changeset/techdocs-poor-forks-repeat.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-techdocs-backend': patch
---
Return a `304 Not Modified` from the `/sync/:namespace/:kind/:name` endpoint if nothing was built. This enables the caller to know whether a refresh of the docs page will return updated content (-> `201 Created`) or not (-> `304 Not Modified`).
.changeset/tender-trees-notice.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-api-docs': patch
---
Move `EntityTypePicker` to be consistent with `CatalogPage` and remove `api:` prefix from entity names
.changeset/thirty-turtles-carry.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-auth-backend': patch
---
Show better error message when configs defined under auth.providers.<provider> are undefined.
.changeset/tricky-carrots-lick.md
+24
View File
@@ -0,0 +1,24 @@
---
'@backstage/plugin-catalog-backend': minor
---
Move `LdapOrgReaderProcessor` from `@backstage/plugin-catalog-backend`
to `@backstage/plugin-catalog-backend-module-ldap`.
The `LdapOrgReaderProcessor` isn't registered by default anymore, if
you want to continue using it you have to register it manually at the catalog
builder:
1. Add dependency to `@backstage/plugin-catalog-backend-module-ldap` to the `package.json` of your backend.
2. Add the processor to the catalog builder:
```typescript
// packages/backend/src/plugins/catalog.ts
builder.addProcessor(
LdapOrgReaderProcessor.fromConfig(config, {
logger,
}),
);
```
For more configuration details, see the [README of the `@backstage/plugin-catalog-backend-module-ldap` package](https://github.com/backstage/backstage/blob/master/plugins/catalog-backend-module-ldap/README.md).
.changeset/twenty-pumpkins-work.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/core-components': patch
---
Clear the previously selected sign-in provider on failure
.changeset/two-pots-joke.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog': patch
---
Get rid of flex console warning for IconLink
.changeset/warm-mangos-share.md
+5
View File
@@ -0,0 +1,5 @@
---
'@backstage/plugin-kafka-backend': patch
---
Properly return a 404 when an unknown cluster is given
.changeset/weak-needles-peel.md
-5
View File
@@ -1,5 +0,0 @@
---
'@backstage/plugin-scaffolder-backend': patch
---
Correctly recognize whether the cookiecutter command exists
.changeset/wet-suits-attack.md
-6
View File
@@ -1,6 +0,0 @@
---
'@backstage/core': patch
'@backstage/core-api': patch
---
Add deprecation warning to package README.
.github/codecov.yml
+8 -4
View File
@@ -14,11 +14,15 @@ coverage:
# Since Backstage is a mono repo, flags here help in getting the code coverage of individual packages.
# Documentation: https://docs.codecov.io/docs/flags
flags:
core:
core-app-api:
paths:
- packages/core/
- packages/core-app-api/
carryforward: true
core-api:
core-components:
paths:
- packages/core-api/
- packages/core-components/
carryforward: true
core-plugin-api:
paths:
- packages/core-plugin-api/
carryforward: true
.github/styles/vocab.txt
+7
View File
@@ -52,10 +52,12 @@ cookiecutter
css
Datadog
dataflow
dayjs
deadnaming
debounce
Debounce
declaratively
deduplicated
deps
destructured
dev
@@ -120,6 +122,7 @@ Knex
kubectl
kubernetes
kubernetes
ldap
learnings
Leasot
lerna
@@ -205,6 +208,8 @@ repo
Repo
repos
rerender
Reusability
reusability
rollbar
Rollbar
Rollup
@@ -222,6 +227,7 @@ seb
semlas
semver
Serverless
siloed
Sinon
Snyk
sourcemaps
@@ -268,6 +274,7 @@ transpilation
transpiled
truthy
ui
unbreak
unmanaged
unregister
unregistration
.github/workflows/chromatic-storybook-test.yml
+1 -2
View File
@@ -4,8 +4,7 @@ on:
paths:
- '.github/workflows/chromatic-storybook-test.yml'
- 'packages/storybook/**'
- 'packages/core/src/components/**'
- 'packages/core/src/layout/**'
- 'packages/core-components/src/**'
jobs:
chromatic:
.github/workflows/master.yml
+3 -2
View File
@@ -119,8 +119,9 @@ jobs:
yarn lerna -- run test -- --coverage
bash <(curl -s https://codecov.io/bash)
# Upload code coverage for some specific flags. Also see .codecov.yml
bash <(curl -s https://codecov.io/bash) -f packages/core/coverage/* -F core
bash <(curl -s https://codecov.io/bash) -f packages/core-api/coverage/* -F core-api
bash <(curl -s https://codecov.io/bash) -f packages/core-app-api/coverage/* -F core-app-api
bash <(curl -s https://codecov.io/bash) -f packages/core-components/coverage/* -F core-components
bash <(curl -s https://codecov.io/bash) -f packages/core-plugin-api/coverage/* -F core-plugin-api
env:
BACKSTAGE_TEST_DATABASE_POSTGRES13_CONNECTION_STRING: postgresql://postgres:postgres@localhost:${{ job.services.postgres13.ports[5432] }}
BACKSTAGE_TEST_DATABASE_POSTGRES9_CONNECTION_STRING: postgresql://postgres:postgres@localhost:${{ job.services.postgres9.ports[5432] }}
.github/workflows/microsite-with-storybook-deploy.yml
+1 -1
View File
@@ -7,7 +7,7 @@ on:
paths:
- '.github/workflows/microsite-with-storybook-deploy.yml'
- 'packages/storybook/**'
- 'packages/core/src/**'
- 'packages/core-components/src/**'
- 'microsite/**'
- 'docs/**'
ADOPTERS.md
+3 -2
View File
@@ -1,7 +1,7 @@
| Organization | Contact | Description of Use |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Spotify](https://www.spotify.com) | [@leemills83](https://github.com/leemills83) | Main interface towards all of Spotify's infrastructure and technical documentation. |
| [bol.com](https://www.bol.com) | [@RoyJacobs](https://github.com/RoyJacobs) | Initial work being done to unify platform tooling. |
| [bol.com](https://www.bol.com) | [@sagacity](https://github.com/sagacity) | Initial work being done to unify platform tooling. |
| [DFDS](https://www.dfds.com) | [@carlsendk](https://github.com/carlsendk) | V2 self-service platform. |
| [Roadie](https://roadie.io) | [@dtuite](https://github.com/dtuite) | Hosted, managed Backstage with easy set-up |
| [Roku](https://www.roku.com) | [@timurista](https://github.com/timurista) | Initial work on Cloud engineering service platform. |
@@ -32,4 +32,5 @@
| [PagerDuty](https://www.pagerduty.com/) | [Mark Shaw](https://github.com/markshawtoronto) | Developer portal, initially focused on software templates and tech-docs. |
| [MoonShiner](https://moonshiner.at) | [Fabian Hippmann](https://github.com/FabianHippmann) | Developer portal - helps us keep track of our customer projects, onboard new developers & improve our development process 🌕🚀🧑‍🚀 |
| [FundApps](https://www.fundapps.co/) | [Elliot Greenwood](https://github.com/egnwd) | Developer Portal - A place for us to keep track of our projects and documentation for all services and processes |
| [DAZN](https://dazn.com/) | [Lou Bichard](https://twitter.com/loujaybee), [Marco Crivellaro](https://github.com/crivetechie) | Ingesting all of DAZN's repos for the catalog, migrating our internal platform apps (pull request boards, release information, inner source marketplace etc) to Backstage plugins (where applicable). |
| [DAZN](https://dazn.com/) | [Lou Bichard](https://twitter.com/loujaybee), [Marco Crivellaro](https://github.com/crivetechie), [Alex Hollerith](mailto:alex.hollerith@dazn.com) | Ingesting all of DAZN's repos for the catalog, migrating our internal platform apps (pull request boards, release information, inner source marketplace etc) to Backstage plugins (where applicable). |
| [HelloFresh](https://www.hellofresh.de/) | [@iammuho](https://github.com/iammuho), [@ElenaForester](https://github.com/ElenaForester), [@diegomarangoni](https://github.com/diegomarangoni) | Our developer portal at HelloFresh - Spread across an organisation of 500+ engineers globally. |
README.md
+4 -4
View File
@@ -12,15 +12,15 @@
## What is Backstage?
[Backstage](https://backstage.io/) is an open platform for building developer portals. Powered by a centralized service catalog, Backstage restores order to your microservices and infrastructure and enables your product teams to ship high-quality code quickly — without compromising autonomy.
[Backstage](https://backstage.io/) is an open platform for building developer portals. Powered by a centralized software catalog, Backstage restores order to your microservices and infrastructure and enables your product teams to ship high-quality code quickly — without compromising autonomy.
Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end.
![service-catalog](https://backstage.io/blog/assets/6/header.png)
![software-catalog](https://backstage.io/blog/assets/6/header.png)
Out of the box, Backstage includes:
- [Backstage Service Catalog](https://backstage.io/docs/features/software-catalog/software-catalog-overview) for managing all your software (microservices, libraries, data pipelines, websites, ML models, etc.)
- [Backstage Software Catalog](https://backstage.io/docs/features/software-catalog/software-catalog-overview) for managing all your software (microservices, libraries, data pipelines, websites, ML models, etc.)
- [Backstage Software Templates](https://backstage.io/docs/features/software-templates/software-templates-index) for quickly spinning up new projects and standardizing your tooling with your organization’s best practices
- [Backstage TechDocs](https://backstage.io/docs/features/techdocs/techdocs-overview) for making it easy to create, maintain, find, and use technical documentation, using a "docs like code" approach
- Plus, a growing ecosystem of [open source plugins](https://github.com/backstage/backstage/tree/master/plugins) that further expand Backstage’s customizability and functionality
@@ -38,7 +38,7 @@ Check out [the documentation](https://backstage.io/docs/getting-started) on how
## Documentation
- [Main documentation](https://backstage.io/docs)
- [Service Catalog](https://backstage.io/docs/features/software-catalog/software-catalog-overview)
- [Software Catalog](https://backstage.io/docs/features/software-catalog/software-catalog-overview)
- [Architecture](https://backstage.io/docs/overview/architecture-overview) ([Decisions](https://backstage.io/docs/architecture-decisions/adrs-overview))
- [Designing for Backstage](https://backstage.io/docs/dls/design)
- [Storybook - UI components](https://backstage.io/storybook)
contrib/docs/tutorials/authenticate-api-requests.md
+1 -1
View File
@@ -99,7 +99,7 @@ async function main() {
```typescript
// packages/app/src/App.tsx from a create-app deployment
import { discoveryApiRef, useApi } from '@backstage/core';
import { discoveryApiRef, useApi } from '@backstage/core-plugin-api';
// ...
contrib/docs/tutorials/aws-alb-aad-oidc-auth.md
+1 -1
View File
@@ -51,7 +51,7 @@ The Backstage App needs a SignInPage when authentication is required.
When using ALB authentication Backstage will only be loaded once the user has successfully authenticated; we won't need to display a SignIn page, however we will need to create a dummy SignIn component that can refresh the token.
- edit `packages/app/src/App.tsx`
- import the following two additional definitions from `@backstage/core`: `useApi`, `configApiRef`; these will be used to check whether Backstage is running locally or behind an ALB
- import the following two additional definitions from `@backstage/core-plugin-api`: `useApi`, `configApiRef`; these will be used to check whether Backstage is running locally or behind an ALB
- add the following definition just before the app is created (`const app = createApp`):
```ts
contrib/docs/tutorials/help-im-behind-a-corporate-proxy.md
+1
View File
@@ -26,6 +26,7 @@ import 'global-agent/bootstrap';
```sh
export GLOBAL_AGENT_HTTP_PROXY=$HTTP_PROXY
export GLOBAL_AGENT_NO_PROXY=$NO_PROXY
yarn start
```
contrib/docs/tutorials/quickstart-app-plugin/ExampleComponent.md
+2 -3
View File
@@ -5,6 +5,7 @@ ExampleComponent.tsx reference
```tsx
import React from 'react';
import { Typography, Grid } from '@material-ui/core';
import { identityApiRef, useApi } from '@backstage/core-plugin-api';
import {
InfoCard,
Header,
@@ -13,9 +14,7 @@ import {
ContentHeader,
HeaderLabel,
SupportButton,
identityApiRef,
useApi,
} from '@backstage/core';
} from '@backstage/core-components';
import { ExampleFetchComponent } from '../ExampleFetchComponent';
export const ExampleComponent = () => {
contrib/docs/tutorials/quickstart-app-plugin/ExampleFetchComponent.md
+2 -7
View File
@@ -6,13 +6,8 @@ ExampleFetchComponent.tsx reference
import React from 'react';
import { useAsync } from 'react-use';
import Alert from '@material-ui/lab/Alert';
import {
Table,
TableColumn,
Progress,
githubAuthApiRef,
useApi,
} from '@backstage/core';
import { githubAuthApiRef, useApi } from '@backstage/core-plugin-api';
import { Table, TableColumn, Progress } from '@backstage/core-components';
import { graphql } from '@octokit/graphql';
const query = `{
docs/api/utility-apis.md
+17 -16
View File
@@ -23,18 +23,18 @@ during their entire life cycle.
Each Utility API is tied to an `ApiRef` instance, which is a global singleton
object without any additional state or functionality, its only purpose is to
reference Utility APIs. `ApiRef`s are created using `createApiRef`, which is
exported by `@backstage/core`. There are many
exported by `@backstage/core-plugin-api`. There are many
[predefined Utility APIs](../reference/utility-apis/README.md) defined in
`@backstage/core`, and they're all exported with a name of the pattern
`*ApiRef`, for example `errorApiRef`.
`@backstage/core-plugin-api`, and they're all exported with a name of the
pattern `*ApiRef`, for example `errorApiRef`.
To access one of the Utility APIs inside a React component, use the `useApi`
hook exported by `@backstage/core`, or the `withApis` HOC if you prefer class
components. For example, the `ErrorApi` can be accessed like this:
hook exported by `@backstage/core-plugin-api`, or the `withApis` HOC if you
prefer class components. For example, the `ErrorApi` can be accessed like this:
```tsx
import React from 'react';
import { useApi, errorApiRef } from '@backstage/core';
import { useApi, errorApiRef } from '@backstage/core-plugin-api';
export const MyComponent = () => {
const errorApi = useApi(errorApiRef);
@@ -52,9 +52,9 @@ Note that there is no explicit type given for `ErrorApi`. This is because the
`errorApiRef` has the type embedded, and `useApi` is able to infer the type.
Also note that consuming Utility APIs is not limited to plugins, it can be done
from any component inside Backstage, including the ones in `@backstage/core`.
The only requirement is that they are beneath the `AppProvider` in the react
tree.
from any component inside Backstage, including the ones in
`@backstage/core-plugin-api`. The only requirement is that they are beneath the
`AppProvider` in the react tree.
## Supplying APIs
@@ -101,13 +101,13 @@ app, and the app itself.
### Core APIs
Starting with the Backstage core library, it provides implementations for all of
the core APIs. The core APIs are the ones exported by `@backstage/core`, such as
the `errorApiRef` and `configApiRef`. You can find a full list of them
[here](../reference/utility-apis/README.md).
the core APIs. The core APIs are the ones exported by
`@backstage/core-plugin-api`, such as the `errorApiRef` and `configApiRef`. You
can find a full list of them [here](../reference/utility-apis/README.md).
The core APIs are loaded for any app created with `createApp` from
`@backstage/core`, which means that there is no step that needs to be taken to
include these APIs in an app.
`@backstage/core-plugin-api`, which means that there is no step that needs to be
taken to include these APIs in an app.
### Plugin APIs
@@ -213,8 +213,9 @@ implement the `ErrorApi`, as it is checked by the type embedded in the
Plugins are free to define their own Utility APIs. Simply define the TypeScript
interface for the API, and create an `ApiRef` using `createApiRef` exported from
`@backstage/core`. Also be sure to provide at least one implementation of the
API, and to declare a default factory for the API in `createPlugin`.
`@backstage/core-plugin-api`. Also be sure to provide at least one
implementation of the API, and to declare a default factory for the API in
`createPlugin`.
Custom Utility APIs can be either public or private, which is up to the plugin
to choose. Private APIs do not expose an external API surface, and it's
docs/architecture-decisions/adr004-module-export-structure.md
+3 -3
View File
@@ -6,8 +6,8 @@ description: Architecture Decision Record (ADR) log on Module Export Structure
## Context
With a growing number of exports of packages like `@backstage/core`, it is
becoming more and more difficult to answer questions such as
With a growing number of exports of packages like `@backstage/core-components`,
it is becoming more and more difficult to answer questions such as
> Is the export in this module also exported by the package?
@@ -86,7 +86,7 @@ import { helperFunc } from '../../lib/UtilityX/helper';
## Consequences
We will actively work to rework the export structure in our codebase,
prioritizing the library packages such as `@backstage/core` and
prioritizing the library packages such as `@backstage/core-components` and
`@backstage/backend-common`.
If possible, we will add tools, such as lint rules, to help enforce the export
docs/architecture-decisions/adr011-plugin-package-structure.md
+6
View File
@@ -35,6 +35,8 @@ example `catalog` or `techdocs`):
- `x`: Contains the main frontend code of the plugin.
- `x-backend`: Contains the main backend code of the plugin.
- `x-backend-module-<name>`: Contains optional modules related to the backend
plugin.
- `x-react`: Contains shared widgets, hooks and similar that both the plugin
itself (`x`) and third-party frontend plugins can depend on.
- `x-node`: Contains utilities for backends that both the plugin backend itself
@@ -61,6 +63,10 @@ We will actively migrate existing packages that are part of a plugin to the
`plugins/catalog-common` we might want to do an exception here, as it's a very
central package.
We will actively migrate optional features of backend plugins into separate
`x-backend-module-<name>` packages, for example the more specialized processors
in the catalog backend.
The limited set of rules might not be sufficient in the future. If additional
packages are required, we will revisit this decision and extend the pattern.
docs/assets/software-catalog/service-catalog-home.png → docs/assets/software-catalog/software-catalog-home.png
View File
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 303 KiB

After

Width:  |  Height:  |  Size: 303 KiB

docs/auth/index.md
+2 -1
View File
@@ -66,7 +66,8 @@ built-in providers:
```diff
# packages/app/src/App.tsx
+ import { githubAuthApiRef, SignInProviderConfig, SignInPage } from '@backstage/core';
+ import { githubAuthApiRef } from '@backstage/core-plugin-api';
+ import { SignInProviderConfig, SignInPage } from '@backstage/core-components';
+ const githubProvider: SignInProviderConfig = {
+ id: 'github-auth-provider',
docs/auth/oauth.md
+4 -4
View File
@@ -14,7 +14,7 @@ to various third party APIs.
There are occasions when the user wants to perform actions towards third party
services that require authorization via OAuth. Backstage provides standardized
[Utility APIs](../api/utility-apis.md) such as the
[GoogleAuthApi](https://github.com/backstage/backstage/blob/master/packages/core-api/src/apis/definitions/auth.ts)
[GoogleAuthApi](https://github.com/backstage/backstage/blob/master/packages/core-plugin-api/src/apis/definitions/auth.ts)
for that use-case. Backstage also includes a set of implementations of these
APIs that integrate with the
[auth-backend](https://github.com/backstage/backstage/tree/master/plugins/auth-backend)
@@ -38,7 +38,7 @@ choose an account to log in with, and accept or reject the request. If the user
accepts the login request, a token is issued, and any holder of the token can
use it to make authenticated requests towards the third party service.
## OAuth in @backstage/core-api and auth-backend
## OAuth in @backstage/core-app-api and auth-backend
The default OAuth implementation in Backstage is based on an OAuth server-side
offline access flow, which means that it uses the backend as a helper in order
@@ -59,8 +59,8 @@ easier to make authenticated requests inside a plugin.
The following describes the OAuth flow implemented by the
[auth-backend](https://github.com/backstage/backstage/tree/master/plugins/auth-backend)
and
[DefaultAuthConnector](https://github.com/backstage/backstage/blob/master/packages/core-api/src/lib/AuthConnector/DefaultAuthConnector.ts)
in `@backstage/core-api`.
[DefaultAuthConnector](https://github.com/backstage/backstage/blob/master/packages/core-app-api/src/lib/AuthConnector/DefaultAuthConnector.ts)
in `@backstage/core-app-api`.
Component and APIs can request Access or ID Tokens from any available Auth
provider. If there already exists a cached fresh token that covers (at least)
docs/auth/using-auth.md
+9 -8
View File
@@ -45,8 +45,8 @@ pieces in place that can be used.
#### Identity for Plugin Developers
As a plugin developer, there are two main touchpoints for identities: the
`IdentityApi` exported by `@backstage/core` via the `identityApiRef`, and a not
yet existing middleware exported by `@backstage/backend-common`.
`IdentityApi` exported by `@backstage/core-plugin-api` via the `identityApiRef`,
and a not yet existing middleware exported by `@backstage/backend-common`.
The `IdentityApi` gives access to the signed-in user's identity in the frontend.
It provides access to the user's ID, lightweight profile information, and an ID
@@ -61,8 +61,9 @@ https://github.com/backstage/backstage/issues/1435.
If you're setting up your own Backstage app, or want to add a new identity
provider, there are three touchpoints: the frontend auth APIs in
`@backstage/core-api`, the backend auth providers in `auth-backend`, and the
`SignInPage` component configured in the Backstage app via `createApp`.
`@backstage/core-app-api` and `@backstage/core-plugin-api`, the backend auth
providers in `auth-backend`, and the `SignInPage` component configured in the
Backstage app via `createApp`.
The frontend APIs and backend providers are tightly coupled together for each
auth provider, and together they implement an e2e auth flow. Only some auth
@@ -81,10 +82,10 @@ The final piece of the puzzle is the `SignInPage` component that can be
configured as part of the app. Without a sign-in page, Backstage will fall back
to a `guest` identity for all users, without any ID token. To enable sign-in, a
`SignInPage` needs to be configured, which in turn has to supply a user to the
app. The `@backstage/core` package provides a basic sign-in page that allows
both the user and the app developer to choose between a couple of different
sign-in methods, or to designate a single provider that may also be logged in to
automatically.
app. The `@backstage/core-components` package provides a basic sign-in page that
allows both the user and the app developer to choose between a couple of
different sign-in methods, or to designate a single provider that may also be
logged in to automatically.
## Further Reading
docs/cli/commands.md
+1 -3
View File
@@ -554,9 +554,7 @@ Options:
Scope: `root`
Validate `@backstage` dependencies within the repo, making sure that there are
no duplicates of packages that might lead to breakages. For example,
`@backstage/core` must not be loaded in twice, so having two different versions
of it installed will cause this command to exit with an error.
no duplicates of packages that might lead to breakages.
By supplying the `--fix` flag the command will attempt to fix any conflict that
can be resolved by editing `yarn.lock`, but will not attempt to search for
docs/conf/reading.md
+2 -2
View File
@@ -112,7 +112,7 @@ example `getString`. These will throw an error if there is no value available.
The [ConfigApi](../reference/utility-apis/Config.md) in the frontend is a
[UtilityApi](../api/utility-apis.md). It's accessible as usual via the
`configApiRef` exported from `@backstage/core`.
`configApiRef` exported from `@backstage/core-plugin-api`.
Depending on the config api in another API is slightly different though, as the
`ConfigApi` implementation is supplied via the App itself and not instantiated
@@ -123,7 +123,7 @@ for an example of how this wiring is done.
For standalone plugin setups in `dev/index.ts`, register a factory with a
statically mocked implementation of the config API. Use the `ConfigReader` from
`@backstage/config` to create an instance and register it for the `configApiRef`
from `@backstage/core`.
from `@backstage/core-plugin-api`.
## Accessing ConfigApi in Backend Plugins
docs/dls/contributing-to-storybook.md
+1 -1
View File
@@ -25,7 +25,7 @@ component, which are then displayed both visually and with sample code to be
copied.
When custom Backstage components are created, they are placed in the
`@backstage/core` package and added to the Storybook.
`@backstage/core-components` package and added to the Storybook.
There may be times where an existing Material-UI component (in
`@material-ui/core`) is sufficient and doesn't need to be wrapped or duplicated.
docs/features/kubernetes/configuration.md
+2 -2
View File
@@ -68,7 +68,7 @@ The base URL to the Kubernetes control plane. Can be found by using the
##### `clusters.\*.name`
A name to represent this cluster, this must be unique within the `clusters`
array. Users will see this value in the Service Catalog Kubernetes plugin.
array. Users will see this value in the Software Catalog Kubernetes plugin.
##### `clusters.\*.authProvider`
@@ -195,7 +195,7 @@ annotations:
#### Labeling Kubernetes components
In order for Kubernetes components to show up in the service catalog as a part
In order for Kubernetes components to show up in the software catalog as a part
of an entity, Kubernetes components themselves can have the following label:
```yaml
docs/features/kubernetes/index.md
+1 -1
View File
@@ -2,7 +2,7 @@
id: overview
title: Kubernetes
sidebar_label: Overview
description: Monitoring Kubernetes based services with the service catalog
description: Monitoring Kubernetes based services with the software catalog
---
Kubernetes in Backstage is a tool that's designed around the needs of service
docs/features/search/getting-started.md
+1 -1
View File
@@ -29,7 +29,7 @@ Backstage app with the following contents:
```tsx
import React from 'react';
import { Content, Header, Page } from '@backstage/core';
import { Content, Header, Page } from '@backstage/core-components';
import { Grid, List, Card, CardContent } from '@material-ui/core';
import {
SearchBar,
docs/features/software-catalog/index.md
+12 -12
View File
@@ -1,29 +1,29 @@
---
id: software-catalog-overview
title: Backstage Service Catalog (alpha)
title: Backstage Software Catalog (alpha)
sidebar_label: Overview
# prettier-ignore
description: The Backstage Service Catalog — actually, a software catalog, since it includes more than just services
description: The Backstage Software Catalog
---
## What is a Service Catalog?
## What is a Software Catalog?
The Backstage Service Catalog — actually, a software catalog, since it includes
The Backstage Software Catalog — actually, a software catalog, since it includes
more than just services — is a centralized system that keeps track of ownership
and metadata for all the software in your ecosystem (services, websites,
libraries, data pipelines, etc). The catalog is built around the concept of
[metadata YAML files](descriptor-format.md) stored together with the code, which
are then harvested and visualized in Backstage.
![service-catalog](https://backstage.io/blog/assets/6/header.png)
![software-catalog](https://backstage.io/blog/assets/6/header.png)
## How it works
Backstage and the Backstage Service Catalog make it easy for one team to manage
Backstage and the Backstage Software Catalog make it easy for one team to manage
10 services — and makes it possible for your company to manage thousands of
them.
More specifically, the Service Catalog enables two main use-cases:
More specifically, the Software Catalog enables two main use-cases:
1. Helping teams manage and maintain the software they own. Teams get a uniform
view of all their software; services, libraries, websites, ML models — you
@@ -37,11 +37,11 @@ The Software Catalog is available to browse at `/catalog`. If you've followed
[Getting Started with Backstage](../../getting-started), you should be able to
browse the catalog at `http://localhost:3000`.
![](../../assets/software-catalog/service-catalog-home.png)
![](../../assets/software-catalog/software-catalog-home.png)
## Adding components to the catalog
The source of truth for the components in your service catalog are
The source of truth for the components in your software catalog are
[metadata YAML files](descriptor-format.md) stored in source control (GitHub,
GitHub Enterprise, GitLab, ...).
@@ -104,11 +104,11 @@ them, and do so using their normal Git workflow.
![](../../assets/software-catalog/bsc-edit.png)
Once the change has been merged, Backstage will automatically show the updated
metadata in the service catalog after a short while.
metadata in the software catalog after a short while.
## Finding software in the catalog
By default the service catalog shows components owned by the team of the logged
By default the software catalog shows components owned by the team of the logged
in user. But you can also switch to _All_ to see all the components across your
company's software ecosystem. Basic inline _search_ and _column filtering_ makes
it easy to browse a big set of components.
@@ -124,7 +124,7 @@ _starring_ of components:
## Integrated tooling through plugins
The service catalog is a great way to organize the infrastructure tools you use
The software catalog is a great way to organize the infrastructure tools you use
to manage the software. This is how Backstage creates one developer portal for
all your tools. Rather than asking teams to jump between different
infrastructure UIs (and incurring additional cognitive overhead each time they
docs/features/software-templates/adding-templates.md
+1 -1
View File
@@ -83,7 +83,7 @@ spec:
[Template Entity](../software-catalog/descriptor-format.md#kind-template)
contains more information about the required fields.
Once we have a `template.yaml` ready, we can then add it to the service catalog
Once we have a `template.yaml` ready, we can then add it to the software catalog
for use by the scaffolder.
You can add the template files to the catalog through
docs/features/software-templates/writing-templates.md
+2 -2
View File
@@ -4,8 +4,8 @@ title: Writing Templates
description: Details around creating your own custom Software Templates
---
Templates are stored in the **Service Catalog** under a kind `Template`. You can
create your own templates with a small `yaml` definition which describes the
Templates are stored in the **Software Catalog** under a kind `Template`. You
can create your own templates with a small `yaml` definition which describes the
template and it's metadata, along with some input variables that your template
will need, and then a list of actions which are then executed by the scaffolding
service.
docs/getting-started/app-custom-theme.md
+1 -1
View File
@@ -56,7 +56,7 @@ For example, adding the theme that we created in the previous section can be
done like this:
```ts
import { createApp } from '@backstage/core';
import { createApp } from '@backstage/core-app-api';
const app = createApp({
apis: ...,
docs/getting-started/contributors.md
+1 -1
View File
@@ -94,7 +94,7 @@ here are some useful ones:
```python
yarn start # Start serving the example app, use --check to include type checks and linting
yarn storybook # Start local storybook, useful for working on components in @backstage/core
yarn storybook # Start local storybook, useful for working on components in @backstage/core-components
yarn workspace @backstage/plugin-welcome start # Serve welcome plugin only, also supports --check
docs/getting-started/create-an-app.md
+6 -5
View File
@@ -137,7 +137,7 @@ frontend with `yarn start` in one window, and the backend with
It can often be useful to try out changes to the packages in the main Backstage
repo within your own app. For example if you want to make modifications to
`@backstage/core` and try them out in your app.
`@backstage/core-plugin-api` and try them out in your app.
To link in external packages, add them to your `package.json` and `lerna.json`
workspace paths. These can be either relative or absolute paths with or without
@@ -147,7 +147,7 @@ globs. For example:
"packages": [
"packages/*",
"plugins/*",
"../backstage/packages/core", // New path added to work on @backstage/core
"../backstage/packages/core-plugin-api", // New path added to work on @backstage/core-plugin-api
],
```
@@ -157,9 +157,10 @@ Then reinstall packages to make yarn set up symlinks:
yarn install
```
With this in place you can now modify the `@backstage/core` package within the
main repo, and have those changes be reflected and tested in your app. Simply
run your app using `yarn dev` (or `yarn start` for just frontend) as normal.
With this in place you can now modify the `@backstage/core-plugin-api` package
within the main repo, and have those changes be reflected and tested in your
app. Simply run your app using `yarn dev` (or `yarn start` for just frontend) as
normal.
Note that for backend packages you need to make sure that linked packages are
not dependencies of any non-linked package. If you for example want to work on
docs/getting-started/project-structure.md
+7 -8
View File
@@ -127,18 +127,17 @@ are separated out into their own folder, see further down.
used by the backend, we chose to separate `config` and `config-loader` into
two different packages.
- [`core/`](https://github.com/backstage/backstage/tree/master/packages/core) -
- [`core-app-api/`](https://github.com/backstage/backstage/tree/master/packages/core-app-api) -
This package contains the core APIs that are used to wire together Backstage
apps.
- [`core-components/`](https://github.com/backstage/backstage/tree/master/packages/core-components) -
This package contains our visual React components, some of which you can find
in
[plugin examples](https://backstage.io/storybook/?path=/story/plugins-examples--plugin-with-data).
Apart from that it re-exports everything from [`core-api`] so that users only
need to rely on one package.
- [`core-api/`](https://github.com/backstage/backstage/tree/master/packages/core-api) -
This package contains APIs and definitions of such. It is it's own package
because we needed to split our `test-utils` package. It's an implementation
detail that we try to hide from our users, and no one should have to depend on
it directly.
- [`core-plugin-api/`](https://github.com/backstage/backstage/tree/master/packages/core-plugin-api) -
This package contains the core APIs that are used to build Backstage plugins.
- [`create-app/`](https://github.com/backstage/backstage/tree/master/packages/create-app) -
An CLI to specifically scaffold a new Backstage App. It does so by using a
docs/integrations/ldap/org.md
+16 -10
View File
@@ -14,19 +14,25 @@ entities that mirror your org setup.
## Installation
The processor that performs the import, `LdapOrgReaderProcessor`, comes
installed with the default setup of Backstage.
1. The processor is not installed by default, therefore you have to add a
dependency to `@backstage/plugin-catalog-backend-module-ldap` to your backend
package.
If you replace the set of processors in your installation using that facility of
the catalog builder class, you can import and add it as follows.
```bash
# From your Backstage root directory
cd packages/backend
yarn add @backstage/plugin-catalog-backend-module-ldap
```
```ts
// Typically in packages/backend/src/plugins/catalog.ts
import { LdapOrgReaderProcessor } from '@backstage/plugin-catalog-backend';
2. The `LdapOrgReaderProcessor` is not registered by default, so you have to
register it in the catalog plugin:
builder.replaceProcessors(
LdapOrgReaderProcessor.fromConfig(config, { logger }),
// ...
```typescript
// packages/backend/src/plugins/catalog.ts
builder.addProcessor(
LdapOrgReaderProcessor.fromConfig(config, {
logger,
}),
);
```
docs/overview/architecture-overview.md
+2 -2
View File
@@ -25,7 +25,7 @@ different ways.
The following diagram shows how Backstage might look when deployed inside a
company which uses the Tech Radar plugin, the Lighthouse plugin, the CircleCI
plugin and the service catalog.
plugin and the software catalog.
There are 3 main components in this architecture:
@@ -142,7 +142,7 @@ Its architecture looks like this:
![lighthouse plugin backed to microservice and database](../assets/architecture-overview/lighthouse-plugin-architecture.png)
The service catalog in Backstage is another example of a service backed plugin.
The software catalog in Backstage is another example of a service backed plugin.
It retrieves a list of services, or "entities", from the Backstage Backend
service and renders them in a table for the user.
docs/overview/background.md
+2 -2
View File
@@ -22,8 +22,8 @@ Our idea was to centralize and simplify end-to-end software development with an
abstraction layer that sits on top of all of our infrastructure and developer
tooling. That’s Backstage.
It’s a developer portal powered by a centralized service catalog — with a plugin
architecture that makes it endlessly extensible and customizable.
It’s a developer portal powered by a centralized software catalog — with a
plugin architecture that makes it endlessly extensible and customizable.
Manage all your services, software, tooling, and testing in Backstage. Start
building a new microservice using an automated template in Backstage. Create,
docs/overview/roadmap.md
+3 -3
View File
@@ -22,7 +22,7 @@ We have divided the project into three high-level _phases_:
[UX patterns and components](https://backstage.io/storybook) help ensure a
consistent experience between tools.
- 🐢 **Phase 2:** Service Catalog
- 🐢 **Phase 2:** Software Catalog
([alpha released](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha)) -
With a single catalog, Backstage makes it easy for a team to manage ten
services — and makes it possible for your company to manage thousands of them.
@@ -120,13 +120,13 @@ Chances are that someone will jump in and help build it.
- [TechDocs v1](https://backstage.io/blog/2020/09/08/announcing-tech-docs)
- [Plugin marketplace](https://backstage.io/plugins)
- [Improved and move documentation to backstage.io](https://backstage.io/docs/overview/what-is-backstage)
- [Backstage Service Catalog (alpha)](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha)
- [Backstage Software Catalog (alpha)](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha)
- [Backstage Software Templates (alpha)](https://backstage.io/blog/2020/08/05/announcing-backstage-software-templates)
- [Make it possible to add custom auth providers](https://backstage.io/blog/2020/07/01/how-to-enable-authentication-in-backstage-using-passport)
- [TechDocs v0](https://github.com/backstage/backstage/milestone/15)
- CI plugins: CircleCI, Jenkins, GitHub Actions and TravisCI
- [Service API documentation](https://github.com/backstage/backstage/pull/1737)
- Backstage Service Catalog can read from: GitHub, GitLab,
- Backstage Software Catalog can read from: GitHub, GitLab,
[Bitbucket](https://github.com/backstage/backstage/pull/1938)
- Support auth providers: Google, Okta, GitHub, GitLab,
[auth0](https://github.com/backstage/backstage/pull/1611),
docs/overview/stability-index.md
+3 -15
View File
@@ -106,16 +106,6 @@ Used to load in static configuration, mainly for use by the CLI and
Stability: `1`. Mainly intended for internal use.
### `core` [GitHub](https://github.com/backstage/backstage/tree/master/packages/core/)
The `@backstage/core` and `@backstage/core-api` packages are being phased out
and replaced by other `@backstage/core-*` packages. They are still in use but
will not receive any breaking changes.
### `core-api` [GitHub](https://github.com/backstage/backstage/tree/master/packages/core-api/)
Stability: See `@backstage/core` above
### `core-app-api` [GitHub](https://github.com/backstage/backstage/tree/master/packages/core-app-api/)
The APIs used exclusively in the app, such as `createApp` and the system icons.
@@ -194,8 +184,9 @@ Stability: `2`
### `test-utils-core` [GitHub](https://github.com/backstage/backstage/tree/master/packages/test-utils-core/)
Internal testing utilities that are separated out for usage in
@backstage/core-api. All exports are re-exported by @backstage/test-utils. This
package should not be depended on directly.
@backstage/core-app-api and @backstage/core-plugin-api. All exports are
re-exported by @backstage/test-utils. This package should not be depended on
directly.
Stability: See @backstage/test-utils
@@ -218,9 +209,6 @@ Stability: `1`
## Plugins
Plugins are rarely marked as stable as the `@backstage/core` plugin API is under
heavy development.
Many backend plugins are split into "REST API" and "TypeScript Interface"
sections. The "TypeScript Interface" refers to the API used to integrate the
plugin into the backend.
docs/overview/what-is-backstage.md
+4 -4
View File
@@ -2,13 +2,13 @@
id: what-is-backstage
title: What is Backstage?
# prettier-ignore
description: Backstage is an open platform for building developer portals. Powered by a centralized service catalog, Backstage restores order to your microservices and infrastructure
description: Backstage is an open platform for building developer portals. Powered by a centralized software catalog, Backstage restores order to your microservices and infrastructure
---
![service-catalog](https://backstage.io/blog/assets/6/header.png)
![software-catalog](https://backstage.io/blog/assets/6/header.png)
[Backstage](https://backstage.io/) is an open platform for building developer
portals. Powered by a centralized service catalog, Backstage restores order to
portals. Powered by a centralized software catalog, Backstage restores order to
your microservices and infrastructure and enables your product teams to ship
high-quality code quickly — without compromising autonomy.
@@ -17,7 +17,7 @@ to create a streamlined development environment from end to end.
Out of the box, Backstage includes:
- [Backstage Service Catalog](../features/software-catalog/index.md) for
- [Backstage Software Catalog](../features/software-catalog/index.md) for
managing all your software (microservices, libraries, data pipelines,
websites, ML models, etc.)
docs/plugins/composability.md
+5 -4
View File
@@ -511,10 +511,11 @@ clarify intent. Refer to the following table to formulate the new name:
## Porting Existing Apps
The first step of porting any app is to replace the root `Routes` component with
`FlatRoutes` from `@backstage/core`. As opposed to the `Routes` component,
`FlatRoutes` only considers the first level of `Route` components in its
children, and provides any additional children to the outlet of the route. It
also removes the need to append `"/*"` to paths, as it is added automatically.
`FlatRoutes` from `@backstage/core-app-api`. As opposed to the `Routes`
component, `FlatRoutes` only considers the first level of `Route` components in
its children, and provides any additional children to the outlet of the route.
It also removes the need to append `"/*"` to paths, as it is added
automatically.
```diff
const AppRoutes = () => (
docs/plugins/index.md
+4 -4
View File
@@ -28,9 +28,9 @@ This helps the community know what plugins are in development.
You can also use this process if you have an idea for a good plugin but you hope
that someone else will pick up the work.
## Integrate into the Service Catalog
## Integrate into the Software Catalog
If your plugin isn't supposed to live as a standalone page, but rather needs to
be presented as a part of a Service Catalog (e.g. a separate tab or a card on an
"Overview" tab), then check out
[the instruction](integrating-plugin-into-service-catalog.md) on how to do it.
be presented as a part of a Software Catalog (e.g. a separate tab or a card on
an "Overview" tab), then check out
[the instruction](integrating-plugin-into-software-catalog.md) on how to do it.
docs/plugins/integrating-plugin-into-service-catalog.md → docs/plugins/integrating-plugin-into-software-catalog.md
+3 -3
View File
@@ -1,7 +1,7 @@
---
id: integrating-plugin-into-service-catalog
title: Integrate into the Service Catalog
description: How to integrate a plugin into service catalog
id: integrating-plugin-into-software-catalog
title: Integrate into the Software Catalog
description: How to integrate a plugin into software catalog
---
> This is an advanced use case and currently is an experimental feature. Expect
docs/plugins/plugin-development.md
+3 -3
View File
@@ -36,7 +36,7 @@ to avoid import cycles, for example like this:
```tsx
/* src/routes.ts */
import { createRouteRef } from '@backstage/core';
import { createRouteRef } from '@backstage/core-plugin-api';
// Note: This route ref is for internal use only, don't export it from the plugin
export const rootRouteRef = createRouteRef({
@@ -46,11 +46,11 @@ export const rootRouteRef = createRouteRef({
Now that we have a `RouteRef`, we import it into `src/plugin.ts`, create our
plugin instance with `createPlugin`, as well as create and wrap our routable
extension using `createRoutableExtension` from `@backstage/core`:
extension using `createRoutableExtension` from `@backstage/core-plugin-api`:
```tsx
/* src/plugin.ts */
import { createPlugin, createRouteRef } from '@backstage/core';
import { createPlugin, createRouteRef } from '@backstage/core-plugin-api';
import ExampleComponent from './components/ExampleComponent';
// Create a plugin instance and export this from your plugin package
docs/plugins/structure-of-a-plugin.md
+4 -1
View File
@@ -57,7 +57,10 @@ package.json to declare the plugin dependencies, metadata and scripts.
In the `src` folder we get to the interesting bits. Check out the `plugin.ts`:
```jsx
import { createPlugin, createRoutableExtension } from '@backstage/core';
import {
createPlugin,
createRoutableExtension,
} from '@backstage/core-plugin-api';
import { rootRouteRef } from './routes';
docs/reference/createPlugin-feature-flags.md
+2 -2
View File
@@ -11,7 +11,7 @@ can use this to split out logic in your code for manual A/B testing, etc.
Here's a code sample:
```typescript
import { createPlugin } from '@backstage/core';
import { createPlugin } from '@backstage/core-plugin-api';
export default createPlugin({
id: 'plugin-name',
@@ -29,7 +29,7 @@ To inspect the state of a feature flag inside your plugin, you can use the
```tsx
import React from 'react';
import { Button } from '@material-ui/core';
import { featureFlagsApiRef, useApi } from '@backstage/core';
import { featureFlagsApiRef, useApi } from '@backstage/core-plugin-api';
const ExamplePage = () => {
const featureFlags = useApi(featureFlagsApiRef);

Some files were not shown because too many files have changed in this diff Show More