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 #1847, #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 #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.
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
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
Patch Changes
ae59833: Fix banner position and color
This PR closes: #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]
@backstage/core-api@0.2.0
Minor Changes
819a702: Add SAML login to backstage
Patch Changes
cbbd271: Add initial RouteRefRegistry
Starting out some work to bring routing back and working as part of the work towards finalizing #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 #1847, #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 #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: #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 #1847, #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 #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]
@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 #688 💵
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 #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 #1847, #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 #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]
@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 #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 #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 #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 #1847, #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.2.0
Patch Changes
@techdocs/cli@0.2.0
Patch Changes
@backstage/test-utils@0.2.0
Patch Changes
@backstage/plugin-graphql-backend@0.2.0
Patch Changes
@backstage/plugin-kubernetes-backend@0.1.1
Patch Changes
@backstage/plugin-mlflow@0.1.1
Patch Changes
@backstage/plugin-rollbar-backend@0.2.0
Patch Changes
@backstage/plugin-sentry-backend@0.2.0
Patch Changes
@backstage/plugin-user-settings@0.1.1
Patch Changes
@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