Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to master, this PR will be updated.
Releases
@backstage/backend-common@0.2.0
Minor Changes
5249594: Add service discovery interface and implement for single host deployments
Fixes RFC: Backend Service Discovery backstage/backstage#1847, Use DiscoveryApi to find the catalog API route in techdocs-backend router. backstage/backstage#2596
Went with an interface similar to the frontend DiscoveryApi, since it's dead simple but still provides a lot of flexibility in the implementation.
Also ended up with two different methods, one for internal endpoint discovery and one for external. The two use-cases are explained a bit more in the docs, but basically it's service-to-service vs callback URLs.
This did get me thinking about uniqueness and that we're heading towards a global namespace for backend plugin IDs. That's probably fine, but if we're happy with that we should leverage it a bit more to simplify the backend setup. For example we'd have each plugin provide its own ID and not manually mount on paths in the backend.
Draft until we're happy with the implementation, then I can add more docs and changelog entry. Also didn't go on a thorough hunt for places where discovery can be used, but I don't think there are many since it's been pretty awkward to do service-to-service communication.
56e4eb5: Make CSP configurable to fix app-backend served app not being able to fetch
See discussion here on discord
e37c0a0: Use localhost to fall back to IPv4 if IPv6 isn't available
f00ca3c: Auto-create plugin databases
Relates to Knex + Plugins (Multiple vs Single Database) backstage/backstage#1598.
This creates databases for plugins before handing off control to plugins.
The list of plugins currently need to be hard-coded depending on the installed plugins. A later PR will properly refactor the code to provide a factory pattern where plugins specify what they need, and Knex instances will be provided based on the input.
8afce08: Use APP_ENV before NODE_ENV for determining what config to load
Patch Changes
440a17b: Added new UrlReader interface for reading opaque data from URLs with different providers.
This new URL reading system is intended as a replacement for the various integrations towards
external systems in the catalog, scaffolder, and techdocs. It is configured via a new top-level
config section called 'integrations'.
Along with the UrlReader interface is a new UrlReaders class, which exposes static factory
methods for instantiating readers that can read from many different integrations simultaneously.
Updated dependencies [ce5512b]
@backstage/catalog-model@0.2.0
Minor Changes
3a42365: Add handling and docs for entity references
e0be86b: Entirely case insensitive read path of entities
f70a528: Add the User & Group entities
A user describes a person, such as an employee, a contractor, or similar. Users belong to Group entities in the catalog.
A group describes an organizational entity, such as for example a team, a business unit, or a loose collection of people in an interest group. Members of these groups are modeled in the catalog as kind User.
12b5fe9: Add ApiDefinitionAtLocationProcessor that allows to load a API definition from another location
a768a07: Add the ability to import users from GitHub Organization into the catalog.
@backstage/cli@0.2.0
Minor Changes
esbuild@0.7.7
Patch Changes
3472c8b: Add codeowners processor
a3840be: Upgrade dependency rollup-plugin-typescript2 to ^0.27.3
cba4e4d: Including source maps with all packages
9a3b3db: Fixed duplicate help output, and print help on invalid command
Updated dependencies [ce5512b]
@backstage/config-loader@0.2.0
Minor Changes
$env: ENV
can be used instead of$secret: { env: ENV }
etc.@backstage/core@0.2.0
Minor Changes
819a702: Add SAML login to backstage
482b631: Fix dense in Structured Metadata Table
1c60f71: Added EmptyState component
b79017f: Updated the
GithubAuth.create
method to configure the default scope of the Github Auth Api. As a result thedefault scope is configurable when overwriting the Core Api in the app.
Patch Changes
ae59833: Fix banner position and color
This PR closes: Fix banner component backstage/backstage#2245
The "fixed" props added to control the position of the banner. When it is set to true the banner will be shown in bottom of that page and the width will be based on the content of the message.
144c66d: Fixed banner component position in DismissableBanner component
Updated dependencies [819a702]
Updated dependencies [ae59833]
Updated dependencies [0d4459c]
Updated dependencies [cbbd271]
Updated dependencies [b79017f]
@backstage/core-api@0.2.0
Minor Changes
819a702: Add SAML login to backstage
b79017f: Updated the
GithubAuth.create
method to configure the default scope of the Github Auth Api. As a result thedefault scope is configurable when overwriting the Core Api in the app.
Patch Changes
cbbd271: Add initial RouteRefRegistry
Starting out some work to bring routing back and working as part of the work towards finalizing Plugin Widgets and Composability backstage/backstage#1536
This is some of the groundwork of an experiment we're working on to enable routing via RouteRefs, while letting the app itself look something like this:
As part of inverting the composition of the app, route refs and routing in general was somewhat broken, intentionally. Right now it's not really possible to easily route to different parts of the app from a plugin, or even different parts of the plugin that are not within the same router.
The core part of the experiment is to construct a map of ApiRef[] -> path overrides. Each key in the map is the list of route refs to traversed to reach a leaf in the routing tree, and the value is the path override at that point. For example, the above tree would add entries like [techDocsRouteRef] -> '/docs', and [entityRouteRef, apiDocsRouteRef] -> '/api'. By mapping out the entire app in this structure, the idea is that we can navigate to any point in the app using RouteRefs.
The RouteRefRegistry is an implementation of such a map, and the idea is to add it in master to make it a bit easier to experiment and iterate. This is not an exposed API at this point.
We've explored a couple of alternatives for how to enable routing, but it's boiled down to either a solution centred around the route map mentioned above, or treating all routes as static and globally unique, with no room for flexibility, customization or conflicts between different plugins. We're starting out pursuing this options 😁. We also expect that a the app-wide routing table will make things like dynamic loading a lot cleaner, as there would be a much more clear handoff between the main chunk and dynamic chunks.
Updated dependencies [ae59833]
Updated dependencies [0d4459c]
@backstage/create-app@0.2.0
Minor Changes
6d29605: Change the default backend plugin mount point to /api
5249594: Add service discovery interface and implement for single host deployments
Fixes RFC: Backend Service Discovery backstage/backstage#1847, Use DiscoveryApi to find the catalog API route in techdocs-backend router. backstage/backstage#2596
Went with an interface similar to the frontend DiscoveryApi, since it's dead simple but still provides a lot of flexibility in the implementation.
Also ended up with two different methods, one for internal endpoint discovery and one for external. The two use-cases are explained a bit more in the docs, but basically it's service-to-service vs callback URLs.
This did get me thinking about uniqueness and that we're heading towards a global namespace for backend plugin IDs. That's probably fine, but if we're happy with that we should leverage it a bit more to simplify the backend setup. For example we'd have each plugin provide its own ID and not manually mount on paths in the backend.
Draft until we're happy with the implementation, then I can add more docs and changelog entry. Also didn't go on a thorough hunt for places where discovery can be used, but I don't think there are many since it's been pretty awkward to do service-to-service communication.
56e4eb5: Make CSP configurable to fix app-backend served app not being able to fetch
See discussion here on discord
d7873e1: Default to using internal scope for new plugins
6f447b3: Remove identity-backend
Not used, and we're heading down the route of identities in the catalog
61db1dd: Allow node v14 and add to master build matrix
a768a07: Add the ability to import users from GitHub Organization into the catalog.
The token needs to have the scopes
user:email
,read:user
, andread:org
.f00ca3c: Auto-create plugin databases
Relates to Knex + Plugins (Multiple vs Single Database) backstage/backstage#1598.
This creates databases for plugins before handing off control to plugins.
The list of plugins currently need to be hard-coded depending on the installed plugins. A later PR will properly refactor the code to provide a factory pattern where plugins specify what they need, and Knex instances will be provided based on the input.
7aff112: The default mount point for backend plugins have been changed to /api. These changes are done in the backend package itself, so it is recommended that you sync up existing backend packages with this new pattern.
Patch Changes
e67d49b: Sync scaffolded backend with example
961414d: Remove discovery api override
440a17b: Bump @backstage/catalog-backend and pass the now required UrlReader interface to the plugin
5a920c6: Updated naming of environment variables. New pattern [NAME]_TOKEN for Github, Gitlab, Azure & Github enterprise access tokens.
Detail:
with latest changes, only single export is sufficient.
list:
67d76b4: Fix for configured templates using 'url' locations even though it's not supported yet
@backstage/theme@0.2.0
Minor Changes
Patch Changes
ae59833: Fix banner position and color
This PR closes: Fix banner component backstage/backstage#2245
The "fixed" props added to control the position of the banner. When it is set to true the banner will be shown in bottom of that page and the width will be based on the content of the message.
@backstage/plugin-api-docs@0.2.0
Minor Changes
28edd7d: Create backend plugin through CLI
3396689: There were some missing features and markdown was not rendered properly, but this is fixed now.
Details:
asyncapi/asyncapi-react#149
- fix: improve markdown rendering of nested fieldsasyncapi/asyncapi-react#150
- feat: display the description of channels and operationsasyncapi/asyncapi-react#153
- fix: let the list ofenums
break into multiple linesPatch Changes
@backstage/plugin-app-backend@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-auth-backend@0.2.0
Minor Changes
28edd7d: Create backend plugin through CLI
819a702: Add SAML login to backstage
6d29605: Change the default backend plugin mount point to /api
5249594: Add service discovery interface and implement for single host deployments
Fixes RFC: Backend Service Discovery backstage/backstage#1847, Use DiscoveryApi to find the catalog API route in techdocs-backend router. backstage/backstage#2596
Went with an interface similar to the frontend DiscoveryApi, since it's dead simple but still provides a lot of flexibility in the implementation.
Also ended up with two different methods, one for internal endpoint discovery and one for external. The two use-cases are explained a bit more in the docs, but basically it's service-to-service vs callback URLs.
This did get me thinking about uniqueness and that we're heading towards a global namespace for backend plugin IDs. That's probably fine, but if we're happy with that we should leverage it a bit more to simplify the backend setup. For example we'd have each plugin provide its own ID and not manually mount on paths in the backend.
Draft until we're happy with the implementation, then I can add more docs and changelog entry. Also didn't go on a thorough hunt for places where discovery can be used, but I don't think there are many since it's been pretty awkward to do service-to-service communication.
6f1768c: Initial implementation of catalog user lookup
This adds a basic catalog client + method for the Google provider to look up users in the catalog. It expects to find a single user entity in the catalog with a google.com/email annotation that matches the email of the Google profile.
Right now it falls back to the old behavior of splitting the email, since I don't wanna break the sign-in flow for existing apps, not yet anyway x).
1687b8f: Lookup user in Google Auth Provider
Patch Changes
@backstage/plugin-catalog@0.2.0
Minor Changes
28edd7d: Create backend plugin through CLI
368fd82: Created EntityNotFound component for catalog which displays the 404 page when entity is not found.
Fixes [catalog] 404 page when entity is not found backstage/backstage#2266
Patch Changes
@backstage/plugin-catalog-backend@0.2.0
Minor Changes
e0be86b: Entirely case insensitive read path of entities
12b5fe9: Add ApiDefinitionAtLocationProcessor that allows to load a API definition from another location
57d555e: This feature works the same as \$secret does in config - it allows programmatic substitution of values into a document.
This is particularly useful e.g. for API type entities where you do not want to repeat your entire API spec document inside the catalog-info.yaml file. For those cases, you can instead do something like
The textual content of that file will be injected as the value of definition, during each refresh loop. Both relative and absolute paths are supported, as well as any HTTP/HTTPS URL pointing to a service that returns the relevant data.
The initial version supports injection of text file data, and structured data from JSON and YAML files. You can add any handler of your own in addition to these.
61db1dd: Allow node v14 and add to master build matrix
81cb943: Simplify the read function in processors
a768a07: Add the ability to import users from GitHub Organization into the catalog.
The token needs to have the scopes
user:email
,read:user
, andread:org
.ce1f553: Use the new
UrlReader
inPlaceholderProcessor
.This allows to use the placeholder processor to include API definitions in API entities.
Previously it was only possible to do this if the definition comes from the same location type as the entity itself.
e6b00e3: Remove the backstage.io/definition-at-location annotation.
The annotation was superseded by the placeholder processor.
512d709: Use the new
UrlReader
in theCodeOwnersProcessor
.49d70cc: Remove the
read
argument ofLocationProcessor.processEntity
.Instead, pass the
UrlReader
into the constructor of yourLocationProcessor
.440a17b: The catalog backend UrlReaderProcessor now uses a UrlReader from @backstage/backend-common, which must now be supplied to the constructor.
Patch Changes
3472c8b: Add codeowners processor
codeowners-utils@^1.0.2
as a dependencycore-js@^3.6.5
as a dependencyUpdated dependencies [3a42365]
Updated dependencies [e0be86b]
Updated dependencies [f70a528]
Updated dependencies [12b5fe9]
Updated dependencies [5249594]
Updated dependencies [56e4eb5]
Updated dependencies [e37c0a0]
Updated dependencies [a768a07]
Updated dependencies [f00ca3c]
Updated dependencies [440a17b]
Updated dependencies [8afce08]
@backstage/plugin-catalog-graphql@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-circleci@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-cost-insights@0.2.0
Minor Changes
cab4737: This PR adds Spotify's Cost Insights Tool. Cost Insights explains costs from cloud services in an understandable way, using software terms familiar to your engineers. This tool helps you and your team make trade-offs between cost optimization efforts and your other priorities.
Cost Insights features:
Daily cost graph by team or billing account
Cost comparison against configurable business metrics
Insights panels for configurable cloud products your company uses
Cost alerts and recommendations
Selectable time periods for month over month, or quarter over quarter cost comparison
Conversion of cost growth into average engineer cost (configurable) to help optimization trade-off decisions
This PR adds the Cost Insights frontend React plugin with a defined CostInsightsApi. We include an example client with static data in the expected format. This API should talk with a cloud billing backend that aggregates billing data from your cloud provider.
Fixes [Plugin] Cloud Cost Insights backstage/backstage#688 💵
6a84cb0: Enable custom alert types in Cost Insights
Patch Changes
@backstage/plugin-explore@0.2.0
Minor Changes
28edd7d: Create backend plugin through CLI
cab4737: This PR adds Spotify's Cost Insights Tool. Cost Insights explains costs from cloud services in an understandable way, using software terms familiar to your engineers. This tool helps you and your team make trade-offs between cost optimization efforts and your other priorities.
Cost Insights features:
Daily cost graph by team or billing account
Cost comparison against configurable business metrics
Insights panels for configurable cloud products your company uses
Cost alerts and recommendations
Selectable time periods for month over month, or quarter over quarter cost comparison
Conversion of cost growth into average engineer cost (configurable) to help optimization trade-off decisions
This PR adds the Cost Insights frontend React plugin with a defined CostInsightsApi. We include an example client with static data in the expected format. This API should talk with a cloud billing backend that aggregates billing data from your cloud provider.
Fixes [Plugin] Cloud Cost Insights backstage/backstage#688 💵
Patch Changes
@backstage/plugin-gcp-projects@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-github-actions@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-gitops-profiles@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-graphiql@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-jenkins@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-kubernetes@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-lighthouse@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-newrelic@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-proxy-backend@0.2.0
Minor Changes
5249594: Add service discovery interface and implement for single host deployments
Fixes RFC: Backend Service Discovery backstage/backstage#1847, Use DiscoveryApi to find the catalog API route in techdocs-backend router. backstage/backstage#2596
Went with an interface similar to the frontend DiscoveryApi, since it's dead simple but still provides a lot of flexibility in the implementation.
Also ended up with two different methods, one for internal endpoint discovery and one for external. The two use-cases are explained a bit more in the docs, but basically it's service-to-service vs callback URLs.
This did get me thinking about uniqueness and that we're heading towards a global namespace for backend plugin IDs. That's probably fine, but if we're happy with that we should leverage it a bit more to simplify the backend setup. For example we'd have each plugin provide its own ID and not manually mount on paths in the backend.
Draft until we're happy with the implementation, then I can add more docs and changelog entry. Also didn't go on a thorough hunt for places where discovery can be used, but I don't think there are many since it's been pretty awkward to do service-to-service communication.
9226c2a: Limit the http headers that are forwarded from the request to a safe set of defaults.
A user can configure additional headers that should be forwarded if the specific applications needs that.
Patch Changes
@backstage/plugin-register-component@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-rollbar@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-scaffolder@0.2.0
Minor Changes
Patch Changes
fb74f1d: Make title meaningful after component creation
Fixes Improve UX of creating new component using Software Template backstage/backstage#2458.
After the change, the UX should look like this:
If the component creation was successful:
If the component creation failed:
Updated dependencies [28edd7d]
Updated dependencies [819a702]
Updated dependencies [3a42365]
Updated dependencies [ae59833]
Updated dependencies [0d4459c]
Updated dependencies [482b631]
Updated dependencies [e0be86b]
Updated dependencies [f70a528]
Updated dependencies [12b5fe9]
Updated dependencies [368fd82]
Updated dependencies [1c60f71]
Updated dependencies [144c66d]
Updated dependencies [a768a07]
Updated dependencies [b79017f]
@backstage/plugin-scaffolder-backend@0.2.0
Minor Changes
3e25450: Add Azure DevOps support to the scaffolder backend
This adds support for Azure DevOps to the scaffolder (preparer & publisher). I thought I should get this in there now since Add GitLab integration for scaffolder backstage/backstage#2426 has been merged. I had a previous PR with only the preparer but I closed that in favor of this one.
I stayed with the 'azure/api' structure but I guess we should try and go the same way as with GitHub here fix(catalog-backend): unify github and github/api, and use git-url-parse backstage/backstage#2501
Patch Changes
@backstage/plugin-sentry@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-tech-radar@0.2.0
Minor Changes
Patch Changes
@backstage/plugin-techdocs@0.2.0
Minor Changes
28edd7d: Create backend plugin through CLI
8351ad7: Add a message if techdocs takes long time to load
Fixes Show a message if TechDocs page takes long time to load (first time visit) backstage/backstage#2416.
The UI after the change should look like this:
Patch Changes
@backstage/plugin-techdocs-backend@0.2.0
Minor Changes
6d29605: Change the default backend plugin mount point to /api
5249594: Add service discovery interface and implement for single host deployments
Fixes RFC: Backend Service Discovery backstage/backstage#1847, Use DiscoveryApi to find the catalog API route in techdocs-backend router. backstage/backstage#2596
Went with an interface similar to the frontend DiscoveryApi, since it's dead simple but still provides a lot of flexibility in the implementation.
Also ended up with two different methods, one for internal endpoint discovery and one for external. The two use-cases are explained a bit more in the docs, but basically it's service-to-service vs callback URLs.
This did get me thinking about uniqueness and that we're heading towards a global namespace for backend plugin IDs. That's probably fine, but if we're happy with that we should leverage it a bit more to simplify the backend setup. For example we'd have each plugin provide its own ID and not manually mount on paths in the backend.
Draft until we're happy with the implementation, then I can add more docs and changelog entry. Also didn't go on a thorough hunt for places where discovery can be used, but I don't think there are many since it's been pretty awkward to do service-to-service communication.
5a920c6: Updated naming of environment variables. New pattern [NAME]_TOKEN for Github, Gitlab, Azure & Github enterprise access tokens.
Detail:
with latest changes, only single export is sufficient.
list:
Patch Changes
@backstage/plugin-welcome@0.2.0
Minor Changes
Patch Changes
@backstage/dev-utils@0.1.1
Patch Changes
@techdocs/cli@0.1.1
Patch Changes
@backstage/test-utils@0.1.1
Patch Changes
@backstage/plugin-graphql-backend@0.1.1
Patch Changes
@backstage/plugin-kubernetes-backend@0.1.1
Patch Changes
@backstage/plugin-rollbar-backend@0.1.1
Patch Changes
@backstage/plugin-sentry-backend@0.1.1
Patch Changes
@backstage/plugin-user-settings@0.1.1
Patch Changes
e2e-test@0.2.0
Minor Changes
yarn e2e-test run
to run@backstage/plugin-cloudbuild@0.2.0
Minor Changes
Patch Changes
example-app@0.2.0
Patch Changes
example-backend@0.2.0
Patch Changes
storybook@0.2.0
Patch Changes