Merge pull request #33704 from backstage/freben/fix-docs-broken-links
docs: fix broken links and anchors across documentation
This commit is contained in:
Fredrik Adelöw
@@ -113,7 +113,7 @@ CMD ["node", "packages/backend", "--config", "app-config.yaml", "--config", "app
|
||||
|
||||
For more details on how the `backend:bundle` command and the `skeleton.tar.gz`
|
||||
file works, see the
|
||||
[`backend:bundle` command docs](../tooling/cli/03-commands.md#backendbundle).
|
||||
[`backend:bundle` command docs](../tooling/cli/03-commands.md#package-bundle).
|
||||
|
||||
The `Dockerfile` is located at `packages/backend/Dockerfile`, but needs to be
|
||||
executed with the root of the repo as the build context, in order to get access
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ brand.
|
||||
No, but it can be! Backstage is designed to be a developer portal for all your
|
||||
infrastructure tooling, services, and documentation. So, it's not a monitoring
|
||||
platform — but that doesn't mean you can't integrate a monitoring tool into
|
||||
Backstage by writing [a plugin](#what-is-a-plugin-in-backstage).
|
||||
Backstage by writing [a plugin](technical.md#what-is-a-plugin-in-backstage).
|
||||
|
||||
### How is Backstage licensed?
|
||||
|
||||
|
||||
@@ -99,7 +99,7 @@ even if a valid ID token was attached that a cluster would authorize.
|
||||
|
||||
## Other known limitations
|
||||
|
||||
The proxy as it was released in [Backstage 1.9](../../releases/v1.9.0-changelog.md#patch-changes-15)
|
||||
The proxy as it was released in [Backstage 1.9](../../releases/v1.9.0-changelog.md)
|
||||
has a known bug:
|
||||
|
||||
- [#15901](https://github.com/backstage/backstage/issues/15901) - it cannot
|
||||
|
||||
@@ -34,7 +34,7 @@ The following sections show the plugins and search engines currently supported b
|
||||
| Plugin | Support Status |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- |
|
||||
| Software Catalog | ✅ |
|
||||
| [TechDocs](./how-to-guides.md#how-to-index-techdocs-documents) | ✅ |
|
||||
| [TechDocs](./how-to-guides.md#how-to-customize-fields-in-the-software-catalog-or-techdocs-index) | ✅ |
|
||||
| [Stack Overflow](https://github.com/backstage/backstage/blob/master/plugins/search-backend-module-stack-overflow-collator/README.md#index-stack-overflow-questions-to-search) | ✅ |
|
||||
|
||||
### Search engines
|
||||
|
||||
@@ -342,4 +342,4 @@ indexBuilder.addCollator({
|
||||
});
|
||||
```
|
||||
|
||||
> For more advanced customization of the Search backend, also see how to guides such as [How to index TechDocs documents](./how-to-guides.md#how-to-index-techdocs-documents) and [How to limit what can be searched in the Software Catalog](./how-to-guides.md#how-to-limit-what-can-be-searched-in-the-software-catalog)
|
||||
> For more advanced customization of the Search backend, also see how to guides such as [How to customize fields in the Software Catalog or TechDocs index](./how-to-guides.md#how-to-customize-fields-in-the-software-catalog-or-techdocs-index)
|
||||
|
||||
@@ -25,7 +25,7 @@ On the technical side, this is unwanted complexity. You need to implement and ma
|
||||
|
||||
On the user experience side, a Backstage experience without complete organizational data is a serious hindrance to getting the full power out of the tool. Your users won't be able to click on owners and seeing who they are and what teams they belong to. They won't be able to find out what the communications paths are when they need to reach you or your managers when something goes wrong or they have a feature request. They can't get an overview of what teams own and how they relate to each other. It will be a much more barren experience. Organizational data is highly valuable to have centrally available, complete and correct.
|
||||
|
||||
## Can I call the catalog itself from inside a processor / provider?
|
||||
## Can I call the catalog itself from inside a processor / provider? {#can-i-call-the-catalog-itself-from-inside-a-processor--provider}
|
||||
|
||||
While it's possible to get hold of a catalog client via the `catalogServiceRef` from `@backstage/plugin-catalog-node`, it's almost never the right thing to do, and we strongly discourage from doing so.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ More specifically, the Software Catalog enables two main use-cases:
|
||||
## Getting Started
|
||||
|
||||
The Software Catalog is available to browse at `/catalog`. If you've followed
|
||||
[Getting Started with Backstage](../../getting-started), you should be able to
|
||||
[Getting Started with Backstage](../../getting-started/index.md), you should be able to
|
||||
browse the catalog at `http://localhost:3000`.
|
||||
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ See the [Writing Custom Actions guide](./writing-custom-actions.md#naming-conven
|
||||
|
||||
## Prerequisites
|
||||
|
||||
These docs assume you have already gone over the [Backstage Getting Started](../../getting-started) section and you are able to run Backstage locally or it has been deployed somewhere.
|
||||
These docs assume you have already gone over the [Backstage Getting Started](../../getting-started/index.md) section and you are able to run Backstage locally or it has been deployed somewhere.
|
||||
|
||||
## Getting Started
|
||||
|
||||
|
||||
@@ -576,7 +576,7 @@ token from the user, which you can do on a per-provider basis, in case your
|
||||
template can be published to multiple providers.
|
||||
|
||||
Note, that you will need to configure an [authentication provider](../../auth/index.md#configuring-authentication-providers), alongside the
|
||||
[`ScmAuthApi`](../../auth/index.md#scaffolder-configuration-software-templates) for your source code management (SCM) service to make this feature work.
|
||||
[`ScmAuthApi`](../../auth/index.md#custom-scmauthapi-implementation) for your source code management (SCM) service to make this feature work.
|
||||
|
||||
### The Repository Branch Picker
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ This page answers frequently asked questions about [TechDocs](README.md).
|
||||
|
||||
- [What static site generator is TechDocs using?](#what-static-site-generator-is-techdocs-using)
|
||||
- [What is the mkdocs-techdocs-core plugin?](#what-is-the-mkdocs-techdocs-core-plugin)
|
||||
- [Does TechDocs support file formats other than Markdown (e.g. RST, AsciiDoc)?](#does-techdocs-support-file-formats-other-than-markdown-eg-rst-asciidoc-)
|
||||
- [Does TechDocs support file formats other than Markdown (e.g. RST, AsciiDoc)?](#does-techdocs-support-file-formats-other-than-markdown-eg-rst-asciidoc)
|
||||
- [What should be the value of `backstage.io/techdocs-ref` when using external build and storage?](#what-should-be-the-value-of-backstageiotechdocs-ref-when-using-external-build-and-storage)
|
||||
- [Is it possible for users to suggest changes or provide feedback on a TechDocs page?](#is-it-possible-for-users-to-suggest-changes-or-provide-feedback-on-a-techdocs-page)
|
||||
|
||||
@@ -30,7 +30,7 @@ plugins (e.g.
|
||||
[MkDocs Monorepo Plugin](https://github.com/spotify/mkdocs-monorepo-plugin)) as
|
||||
well as a selection of Python Markdown extensions that TechDocs supports.
|
||||
|
||||
#### Does TechDocs support file formats other than Markdown (e.g. RST, AsciiDoc) ?
|
||||
#### Does TechDocs support file formats other than Markdown (e.g. RST, AsciiDoc)?
|
||||
|
||||
Not right now. We are currently using MkDocs to generate the documentation from
|
||||
source, so the files have to be in Markdown format. However, in the future we
|
||||
|
||||
@@ -17,8 +17,7 @@ out-of-the box experience.
|
||||
|
||||
See below for our recommended deployment architecture which takes care
|
||||
of stability, scalability and speed. Also look at the
|
||||
[HOW TO migrate guide](how-to-guides
|
||||
md#how-to-migrate-from-techdocs-basic-to-recommended-deployment-approach).
|
||||
[HOW TO migrate guide](how-to-guides.md#how-to-migrate-from-techdocs-basic-to-recommended-deployment-approach).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -104,7 +104,7 @@ the TechDocs plugin in your Backstage app.
|
||||
|
||||
Here is an example workflow using GitHub Actions CI and AWS S3 storage. You can
|
||||
use any CI and any other
|
||||
[TechDocs supported cloud storage providers](README.md#platforms-supported).
|
||||
[TechDocs supported cloud storage providers](README.md#supported).
|
||||
|
||||
Add a `.github/workflows/techdocs.yml` file in your
|
||||
[Software Template(s)](../software-templates/index.md) like this -
|
||||
|
||||
@@ -96,7 +96,7 @@ Utility APIs that are first materialized during bootstrap are frozen for the lif
|
||||
|
||||
## Plugin Info Resolution
|
||||
|
||||
When a plugin is installed in an app it may provide sources of information about the plugin that can be useful to end users and admins. This includes things like what version of a plugin is running, what team owns the plugin, and who to contact for support. You can read more about how the plugins provide this information in the [plugins `info` option section](./15-plugins.md#info).
|
||||
When a plugin is installed in an app it may provide sources of information about the plugin that can be useful to end users and admins. This includes things like what version of a plugin is running, what team owns the plugin, and who to contact for support. You can read more about how the plugins provide this information in the [plugins `info` option section](./15-plugins.md#info-option).
|
||||
|
||||
By default the app will pick a few common fields from `package.json` files, and assume that the opaque manifests are `catalog-info.yaml` files that some information can be gathered from too. This information will then be available via the `info()` method on plugin instances, returning a structure of the `FrontendPluginInfo` type.
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ Each extensions has a number of different properties that define how it behaves
|
||||
|
||||
The ID of an extension is used to uniquely identity it, and it should ideally be unique across the entire Backstage ecosystem. For each frontend app instance there can only be a single extension for any given ID. Installing multiple extensions with the same ID will either result in an error or one of the extensions will override the others. The ID is also used to reference the extensions from other extensions, in configuration, and in other places such as developer tools and analytics.
|
||||
|
||||
When creating an extension you do not provide the ID directly. Instead, you indirectly or directly provide the kind, namespace, and name parts that make up the ID. The kind is always provided by the [extension blueprint](./23-extension-blueprints.md), the only exception is if you use [`createExtension`](#creating-an-extensions) directly. Any extension that is provided by a plugin will by default have its namespace set to the plugin ID, so you generally only need to provide an explicit namespace if you want to override an existing extension. The name is also optional, and primarily used to distinguish between multiple extensions of the same kind and namespace. If a plugin doesn't need to distinguish between different extensions of the same kind, the name can be omitted.
|
||||
When creating an extension you do not provide the ID directly. Instead, you indirectly or directly provide the kind, namespace, and name parts that make up the ID. The kind is always provided by the [extension blueprint](./23-extension-blueprints.md), the only exception is if you use [`createExtension`](#creating-an-extension) directly. Any extension that is provided by a plugin will by default have its namespace set to the plugin ID, so you generally only need to provide an explicit namespace if you want to override an existing extension. The name is also optional, and primarily used to distinguish between multiple extensions of the same kind and namespace. If a plugin doesn't need to distinguish between different extensions of the same kind, the name can be omitted.
|
||||
|
||||
The extension ID will be constructed using the pattern `[<kind>:][<namespace>][/][<name>]`, where the separating `/` is only present if both a namespace and name are defined.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ description: Frontend extension overrides
|
||||
|
||||
An important customization point in the frontend system is the ability to override existing extensions. It can be used for anything from slight tweaks to the extension logic, to completely replacing an extension with a custom implementation. While extensions are encouraged to make themselves configurable, there are many situations where you need to override an extension to achieve the desired behavior. The ability to override extensions should be kept in mind when building plugins, and can be a powerful tool to allow for deeper customizations without the need to re-implement large parts of the plugin.
|
||||
|
||||
In general, most features should have a good level of customization built into them, so that users do not have to leverage extension overrides to achieve common goals. A well written feature often has [configuration](../../conf/) settings, or uses extension inputs for extensibility where applicable. An example of this is the search plugin, which allows you to provide result renderers as inputs rather than replacing the result page wholesale just to tweak how results are shown. Adopters should take advantage of those when possible in order to reduce the need and size of extension overrides.
|
||||
In general, most features should have a good level of customization built into them, so that users do not have to leverage extension overrides to achieve common goals. A well written feature often has [configuration](../../conf/index.md) settings, or uses extension inputs for extensibility where applicable. An example of this is the search plugin, which allows you to provide result renderers as inputs rather than replacing the result page wholesale just to tweak how results are shown. Adopters should take advantage of those when possible in order to reduce the need and size of extension overrides.
|
||||
|
||||
Extension overrides can also replace or remove existing `if` predicates. This applies both to direct extension overrides through `.override(...)` and to plugin-level overrides through `plugin.withOverrides(...)`. Frontend modules can use the same extension override mechanism to adjust or clear the condition for an overridden extension.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ frontend _features_, and what you install to build up a Backstage frontend [app]
|
||||
|
||||
## Creating a new plugin
|
||||
|
||||
This guide assumes that you already have a Backstage project set up. Even if you only want to develop a single plugin for publishing, we still recommend that you do so in a standard Backstage monorepo project, as you often end up needing multiple packages. For instructions on how to set up a new project, see our [getting started](../../getting-started/index.md#prerequisites) documentation.
|
||||
This guide assumes that you already have a Backstage project set up. Even if you only want to develop a single plugin for publishing, we still recommend that you do so in a standard Backstage monorepo project, as you often end up needing multiple packages. For instructions on how to set up a new project, see our [getting started](../../getting-started/index.md) documentation.
|
||||
|
||||
To create a frontend plugin, run `yarn new`, select `plugin`, and fill out the rest of the prompts. This will create a new package at `plugins/<pluginId>`, which will be the main entrypoint for your plugin.
|
||||
|
||||
|
||||
@@ -210,4 +210,4 @@ If you've updated the configuration for your integration, it's likely that the b
|
||||
Some helpful links, for if you want to learn more about:
|
||||
|
||||
- [Other available integrations](../../integrations/index.md)
|
||||
- [Using GitHub Apps instead of a Personal Access Token](../../integrations/github/github-apps.md#docsNav)
|
||||
- [Using GitHub Apps instead of a Personal Access Token](../../integrations/github/github-apps.md)
|
||||
|
||||
@@ -236,4 +236,4 @@ If you've updated the configuration for your integration, it's likely that the b
|
||||
Some helpful links, for if you want to learn more about:
|
||||
|
||||
- [Other available integrations](../../integrations/index.md)
|
||||
- [Using GitHub Apps instead of a Personal Access Token](../../integrations/github/github-apps.md#docsNav)
|
||||
- [Using GitHub Apps instead of a Personal Access Token](../../integrations/github/github-apps.md)
|
||||
|
||||
@@ -190,7 +190,7 @@ backend:
|
||||
# highlight-remove-end
|
||||
```
|
||||
|
||||
[Start the Backstage app](../index.md#2-run-the-backstage-app):
|
||||
[Start the Backstage app](../index.md#creating-and-running-a-backstage-application):
|
||||
|
||||
```shell
|
||||
yarn start
|
||||
|
||||
@@ -39,7 +39,7 @@ At the end of this tutorial, you can expect:
|
||||
Before we begin, make sure
|
||||
|
||||
- You have created your own standalone Backstage app using
|
||||
[`@backstage/create-app`](./index.md#1-create-your-backstage-app) and not
|
||||
[`@backstage/create-app`](./index.md#creating-and-running-a-backstage-application) and not
|
||||
using a fork of the [backstage](https://github.com/backstage/backstage)
|
||||
repository.
|
||||
- You do not have an existing homepage, and by default you are redirected to
|
||||
|
||||
@@ -26,7 +26,7 @@ At the end of this tutorial, you can expect:
|
||||
|
||||
Before we begin, make sure
|
||||
|
||||
- You have created your own standalone Backstage app using [`@backstage/create-app`](./index.md#1-create-your-backstage-app) and not using a fork of the [backstage](https://github.com/backstage/backstage) repository.
|
||||
- You have created your own standalone Backstage app using [`@backstage/create-app`](./index.md#creating-and-running-a-backstage-application) and not using a fork of the [backstage](https://github.com/backstage/backstage) repository.
|
||||
- You do not have an existing homepage, and by default you are redirected to Software Catalog when you open Backstage.
|
||||
|
||||
Now, let's get started by installing the home plugin and creating a simple homepage for your Backstage app.
|
||||
|
||||
@@ -155,7 +155,7 @@ On Node.js 22.21.0+, the Backstage CLI respects the standard `HTTP_PROXY`, `HTTP
|
||||
|
||||
On older Node.js versions, the CLI falls back to [global-agent](https://www.npmjs.com/package/global-agent) and `undici` for proxy support, which require their own environment variables (prefixed with `GLOBAL_AGENT_`). This allows you to route the CLI’s network traffic through a proxy server, which can be useful in environments with restricted internet access.
|
||||
|
||||
Additionally, yarn needs a proxy too (sometimes), when in environments with restricted internet access. It uses different settings than the other modules. If you decide to use the backstage yarn plugin [mentioned above](#plugin), you will need to set additional proxy values.
|
||||
Additionally, yarn needs a proxy too (sometimes), when in environments with restricted internet access. It uses different settings than the other modules. If you decide to use the backstage yarn plugin [mentioned above](#managing-package-versions-with-the-backstage-yarn-plugin), you will need to set additional proxy values.
|
||||
If you will always need proxy settings in all environments and situations, you can add `httpProxy` and `httpsProxy` values to [the yarnrc.yml file](https://yarnpkg.com/configuration/yarnrc). If some environments need it (say a developer workstation) but other environments do not (perhaps a CI build server running on AWS), then you may not want to update the yarnrc.yml file but just set environment variables `YARN_HTTP_PROXY` and `YARN_HTTPS_PROXY` in the environments/situations where you need to proxy.
|
||||
|
||||
**If you plan to use the backstage yarn plugin, you will need these extra yarn proxy settings to both install the plugin and run the `versions:bump` command**. If you do not plan to use the backstage yarn plugin, it seems like the proxy settings alone are sufficient.
|
||||
|
||||
@@ -27,7 +27,7 @@ Initially, the Catalog displays registered entities matching the following filte
|
||||
- `Kind` - Component
|
||||
- `Type` - all
|
||||
- `Owner` - Owned
|
||||
- `Lifecycle` - list of [lifecycle](../features/software-catalog/descriptor-format.md#speclifecycle-required-1) values of entities in the Catalog
|
||||
- `Lifecycle` - list of [lifecycle](../features/software-catalog/descriptor-format.md#speclifecycle-required) values of entities in the Catalog
|
||||
- `Processing Status` - normal
|
||||
- `Namespace` - The ID of a [namespace](../features/software-catalog/descriptor-format.md#namespace-optional) to which the entity belongs
|
||||
|
||||
|
||||
@@ -146,7 +146,7 @@ On Node.js 22.21.0+, the Backstage CLI respects the standard `HTTP_PROXY`, `HTTP
|
||||
|
||||
On older Node.js versions, the CLI falls back to [global-agent](https://www.npmjs.com/package/global-agent) and `undici` for proxy support, which require their own environment variables (prefixed with `GLOBAL_AGENT_`). This allows you to route the CLI’s network traffic through a proxy server, which can be useful in environments with restricted internet access.
|
||||
|
||||
Additionally, `yarn` needs a proxy too (sometimes), when in environments with restricted internet access. It uses different settings than the other modules. If you decide to use the backstage yarn plugin [mentioned above](#plugin), you will need to set additional proxy values.
|
||||
Additionally, `yarn` needs a proxy too (sometimes), when in environments with restricted internet access. It uses different settings than the other modules. If you decide to use the backstage yarn plugin [mentioned above](#managing-package-versions-with-the-backstage-yarn-plugin), you will need to set additional proxy values.
|
||||
If you will always need proxy settings in all environments and situations, you can add `httpProxy` and `httpsProxy` values to [the yarnrc.yml file](https://yarnpkg.com/configuration/yarnrc). If some environments need it (say a developer workstation) but other environments do not (perhaps a CI build server running on AWS), then you may not want to update the yarnrc.yml file but just set environment variables `YARN_HTTP_PROXY` and `YARN_HTTPS_PROXY` in the environments/situations where you need to proxy.
|
||||
|
||||
**If you plan to use the backstage yarn plugin, you will need these extra yarn proxy settings to both install the plugin and run the `versions:bump` command**. If you do not plan to use the backstage yarn plugin, it seems like the proxy settings alone are sufficient.
|
||||
|
||||
@@ -120,7 +120,7 @@ microsoftGraphOrg:
|
||||
In addition to these groups, one additional group will be created for your organization.
|
||||
All imported groups will be a child of this group.
|
||||
|
||||
By default the provider will get groups using the msgraph `/group` endpoint, but it is possible to use different endpoints by setting the `path` configuration. All the endpoint containing `/microsoft.graph.group` will return the right type of group object. [See usage](#Using-path-parameter) for more details.
|
||||
By default the provider will get groups using the msgraph `/group` endpoint, but it is possible to use different endpoints by setting the `path` configuration. All the endpoint containing `/microsoft.graph.group` will return the right type of group object. [See usage](#using-path-parameter) for more details.
|
||||
|
||||
### Users
|
||||
|
||||
@@ -145,7 +145,7 @@ microsoftGraphOrg:
|
||||
search: '"description:One" AND ("displayName:Video" OR "displayName:Drive")'
|
||||
```
|
||||
|
||||
By default the provider will get user using the msgraph `/user` endpoint, but it is possible to use different endpoints by setting the `path` configuration. All the endpoint containing `/microsoft.graph.user` will return the right type of user object. [See usage](#Using-path-parameter) for more details.
|
||||
By default the provider will get user using the msgraph `/user` endpoint, but it is possible to use different endpoints by setting the `path` configuration. All the endpoint containing `/microsoft.graph.user` will return the right type of user object. [See usage](#using-path-parameter) for more details.
|
||||
|
||||
### Using `path` parameter
|
||||
|
||||
|
||||
@@ -22,6 +22,6 @@ In many cases, a permission represents a user's interaction with another object.
|
||||
|
||||
### Conditional decisions
|
||||
|
||||
[Rules](../references/glossary.md#rule-permission-plugin) need additional data before they can be used in a decision. Once a [rule](../references/glossary.md#rule-permission-plugin) is bound to relevant information it forms a [condition](../references/glossary.md#condition-permission-plugin). Conditional decisions tell the [permission framework](#permission) to delegate evaluation to the [plugin](#plugin) that owns the corresponding [resource](#resource-permission-plugin). Permission requests that result in a conditional decision are allowed if all of the provided conditions evaluate to be true.
|
||||
[Rules](../references/glossary.md#rule-permission-plugin) need additional data before they can be used in a decision. Once a [rule](../references/glossary.md#rule-permission-plugin) is bound to relevant information it forms a [condition](../references/glossary.md#condition-permission-plugin). Conditional decisions tell the [permission framework](#permission) to delegate evaluation to the [plugin](../references/glossary.md#plugin) that owns the corresponding [resource](../references/glossary.md#resource-permission-plugin). Permission requests that result in a conditional decision are allowed if all of the provided conditions evaluate to be true.
|
||||
|
||||
A good example would be the catalog plugin's "has annotation" rule which needs to know what annotation to look for on a given entity. The permission framework would respond to a request by the catalog plugin in this case with a condition decision. The catalog plugin would then need to correctly filter for entities matching the "has annotations" condition. This conditional behavior avoids coupling between policies and resource schemas, and allows plugins to evaluate complex rules in an efficient way. For example, a plugin may convert a conditional decision to a database query instead of loading and filtering objects in memory.
|
||||
|
||||
+2
-2
@@ -47,12 +47,12 @@ Additional steps for the main line release
|
||||
- Check for mentions of "major" & "breaking" and if they are expected in the current release
|
||||
- Verify the version we are shipping is correct
|
||||
- Create Release Notes
|
||||
- There exists a [release notes template](./.release-notes-template.md) for creating the release notes. It can already be created after the last main line release to keep track of major changes during the month
|
||||
- There exists a release notes template (`.release-notes-template.md`) for creating the release notes. It can already be created after the last main line release to keep track of major changes during the month
|
||||
- The content is picked by relevancy showcasing the work of the community during the month of the release
|
||||
- Mention newly added packages or features
|
||||
- Mention any security fixes
|
||||
- Create Release Notes PR
|
||||
- Add the release note file as [`/docs/releases/vx.y.0.md`](./releases)
|
||||
- Add the release note file as [`/docs/releases/vx.y.0.md`](https://backstage.io/docs/releases/)
|
||||
- Finally copy the content, without the metadata header, into the description of the [`Version Packages` Pull Request](https://github.com/backstage/backstage/pulls?q=is%3Aopen+is%3Apr+in%3Atitle+%22Version+Packages)
|
||||
|
||||
Once the release has been published edit the newly created release in the [GitHub repository](https://github.com/backstage/backstage/releases) and replace the text content with the release notes.
|
||||
|
||||
@@ -186,7 +186,7 @@ This standard is a key component of [OpenID Connect](#openid-connect-aka-oidc).
|
||||
|
||||
Classification of an [entity](#entity) in the Backstage Software Catalog, for example _service_, _database_, or _team_. An element of the [kind|namespace|name triplet](#kind-namespace-name-triplet) that is an important concept for uniqueness.
|
||||
|
||||
## Kind|namespace|name triplet
|
||||
## Kind|namespace|name triplet {#kind-namespace-name-triplet}
|
||||
|
||||
The primary reference for [Software Catalog](#software-catalog) entities. It is human-readable and should be unique across your Backstage instance.
|
||||
|
||||
@@ -379,7 +379,7 @@ Existing search technology that [Backstage Search](#search) can take advantage o
|
||||
|
||||
The Software Catalog is a core feature of Backstage. See [Backstage Software Catalog](https://backstage.io/docs/next/features/software-catalog/) for an overview, the life of an entity in the catalog, how to configure the catalog, its architecture and high-level design, how to configure and customize it, and its API. The overview describes how the catalog works, how to add components to it, how to find software in it, and more.
|
||||
|
||||
## Software Templates (aka Scaffolder)
|
||||
## Software Templates (aka Scaffolder) {#software-templates}
|
||||
|
||||
1. A "skeleton" software project created and managed in the Backstage Software Templates tool.
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ Several new [entity providers](https://backstage.io/docs/features/software-catal
|
||||
|
||||
- `AzureDevOpsEntityProvider` as replacement for `AzureDevOpsDiscoveryProcessor`. PR [#11604](https://github.com/backstage/backstage/pull/11604) contributed by [@goenning](https://github.com/goenning)
|
||||
- `GitlabDiscoveryEntityProvider` as replacement for `GitLabDiscoveryProcessor`. PR [#11886](https://github.com/backstage/backstage/pull/11886) contributed by [@ivangonzalezacuna](https://github.com/ivangonzalezacuna)
|
||||
- `BitbucketCloudEntityProvider` as a replacement for `BitbucketDiscoveryProcessor` (for Bitbucket Cloud only). PR [#11345](https://github.com/backstage/backstage/pull/11345) contributed by [@pjungermann](https://github.com/pjungermann)
|
||||
- `BitbucketCloudEntityProvider` as a replacement for `BitbucketDiscoveryProcessor` (for Bitbucket Cloud only). PR [#11345](https://github.com/backstage/backstage/pull/11345) contributed by [@pjungermann](https://github.com/pjungermann)
|
||||
|
||||
### New plugin: Vault
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ If your plugin requires access to an API, backstage offers
|
||||
- [Option 2: Defining the API client interface](#defining-the-api-client-interface)
|
||||
- [Creating the API client](#creating-the-api-client)
|
||||
- [Bundling your ApiRef with your plugin](#bundling-your-apiref-with-your-plugin)
|
||||
- [Using the API in your components](#using-your-plugin-in-your-components)
|
||||
- [Using the API in your components](#using-the-api-in-your-components)
|
||||
|
||||
## Setting up the backstage proxy
|
||||
|
||||
@@ -46,7 +46,7 @@ proxy:
|
||||
You can find more details about the proxy config options in the
|
||||
[proxying section](../plugins/proxying.md).
|
||||
|
||||
# Calling an API using the backstage proxy
|
||||
## Calling an API using the backstage proxy
|
||||
|
||||
If you followed the previous steps, you should now be able to access your API by
|
||||
calling `${backend-url}/api/proxy/<your-proxy-uri>`. The reason why
|
||||
|
||||
@@ -50,7 +50,7 @@ yarn start
|
||||
|
||||
And you are good to go! 👍
|
||||
|
||||
Read the full documentation on how to [create an app](/docs/getting-started/create-an-app) on GitHub.
|
||||
Read the full documentation on how to [create an app](/docs/getting-started/) on GitHub.
|
||||
|
||||
## What do I get? (Let's get technical...)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user