Merge branch 'backstage:master' into master
This commit is contained in:
@@ -140,6 +140,9 @@ const app = createApp({
|
||||
});
|
||||
```
|
||||
|
||||
> NOTE: You can configure sign-in to use a redirect flow with no pop-up by adding
|
||||
> `enableExperimentalRedirectFlow: true` to the root of your `app-config.yaml`
|
||||
|
||||
## Sign-In with Proxy Providers
|
||||
|
||||
Some auth providers are so-called "proxy" providers, meaning they're meant to be used
|
||||
|
||||
@@ -676,6 +676,35 @@ and publish the documentation for them. If the value of the `company.com/techdoc
|
||||
annotation is anything other than `'local'`, the user is responsible for publishing
|
||||
documentation to the appropriate location in the TechDocs external storage.
|
||||
|
||||
## How to use other mkdocs plugins?
|
||||
|
||||
The default plugin [mkdocs-techdocs-core](https://github.com/backstage/mkdocs-techdocs-core) provides a set of plugins that can be viewed as the minimum required plugins to enable TechDocs. Your organization might have needs beyond the core set though, here is the recommended way to enable other plugins.
|
||||
|
||||
### Install the plugin
|
||||
|
||||
#### With CI generation
|
||||
|
||||
If you generate the HTML files in CI using `@techdocs/cli`, you need to install the desired mkdocs plugin in the runtime where the cli is being executed. This might be e.g. a docker image or a Jenkins node. Use the `--no-docker` flag with the cli to pick up the plugin you just installed.
|
||||
|
||||
#### With local generation
|
||||
|
||||
Create a new Docker image that extends [spotify/techdocs](https://github.com/backstage/techdocs-container), roughly:
|
||||
|
||||
```Dockerfile
|
||||
FROM spotify/techdocs:<version>
|
||||
|
||||
pip install <the_plugin_you_want>
|
||||
...
|
||||
```
|
||||
|
||||
Then publish the image and use it in your config under the `techdocs.generator.dockerImage` [key](https://github.com/backstage/techdocs-container).
|
||||
|
||||
### Specify the plugin in the mkdocs config
|
||||
|
||||
To use the plugin, it has to be listed in the `mkdocs.yaml` file. You can either add the plugin to your applicable files, or specify defaults.
|
||||
|
||||
To make a mkdocs plugin available for all your TechDocs components you can either list it in the `techdocs.generator.mkdocs.defaultPlugins` [config](https://github.com/backstage/backstage/blob/master/plugins/techdocs-backend/config.d.ts#L64C14-L64C14), or use the `--defaultPlugin` [cli option](https://backstage.io/docs/features/techdocs/cli#generate-techdocs-site-from-a-documentation-project) depending on your setup.
|
||||
|
||||
## Reference another components TechDocs
|
||||
|
||||
In systems where you might have multiple entities for example a System with a Website and an API, when served from a Monorepo you might want to keep the TechDocs in one location in the repository.
|
||||
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
id: customization
|
||||
title: Customization (Experimental)
|
||||
description: Documentation on adding a customization logic to the plugin
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The Backstage core logic provides a possibility to make the component customizable in such a way that the application
|
||||
developer can redefine the labels, icons, elements or even completely replace the component. It's up to each plugin
|
||||
to decide what can be customized.
|
||||
|
||||
## For a plugin developer
|
||||
|
||||
When you are creating your plugin, you have a possibility to use a metadata field and define there all
|
||||
customizable elements. For example
|
||||
|
||||
```typescript jsx
|
||||
const plugin = createPlugin({
|
||||
id: 'my-plugin',
|
||||
__experimentalConfigure(
|
||||
options?: CatalogInputPluginOptions,
|
||||
): CatalogPluginOptions {
|
||||
const defaultOptions = {
|
||||
createButtonTitle: 'Create',
|
||||
};
|
||||
return { ...defaultOptions, ...options };
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
And the rendering part of the exposed component can retrieve that metadata as:
|
||||
|
||||
```typescript jsx
|
||||
export type CatalogPluginOptions = {
|
||||
createButtonTitle: string;
|
||||
};
|
||||
|
||||
export type CatalogInputPluginOptions = {
|
||||
createButtonTitle: string;
|
||||
};
|
||||
|
||||
export const useCatalogPluginOptions = () =>
|
||||
usePluginOptions<CatalogPluginOptions>();
|
||||
|
||||
export function DefaultMyPluginWelcomePage() {
|
||||
const { createButtonTitle } = useCatalogPluginOptions();
|
||||
|
||||
return (
|
||||
<div>
|
||||
<button>{createButtonTitle}</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## For an application developer using the plugin
|
||||
|
||||
The way to reconfigure the default values provided by the plugin you can do it via reconfigure method, defined on the
|
||||
plugin. Example:
|
||||
|
||||
```typescript jsx
|
||||
import { myPlugin } from '@backstage/my-plugin';
|
||||
|
||||
myPlugin.__experimentalReconfigure({
|
||||
createButtonTitle: 'New',
|
||||
});
|
||||
```
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user