From ac8711302fd0ad7ace1cbb1397db0eaed84a597b Mon Sep 17 00:00:00 2001 From: Tomas Kral Date: Fri, 22 Nov 2024 15:15:45 +0100 Subject: [PATCH] docs: fix grammar and style issues (#1974) * docs: fix grammar and style issues * docs: fix e2e readme links --- docs/dynamic-plugins/debugging.md | 36 +++++++++---------- .../dynamic-plugins/export-derived-package.md | 10 +++--- .../dynamic-plugins/frontend-plugin-wiring.md | 26 +++++++------- docs/dynamic-plugins/installing-plugins.md | 8 ++--- docs/dynamic-plugins/local.md | 2 +- .../dynamic-plugins/override-core-services.md | 5 ++- .../packaging-dynamic-plugins.md | 8 ++--- e2e-tests/README.md | 6 ++-- 8 files changed, 50 insertions(+), 51 deletions(-) diff --git a/docs/dynamic-plugins/debugging.md b/docs/dynamic-plugins/debugging.md index c04afa349f..9a9b4e7d7e 100644 --- a/docs/dynamic-plugins/debugging.md +++ b/docs/dynamic-plugins/debugging.md @@ -7,7 +7,7 @@ For local debugging of Dynamic Plugins you need to clone `backstage-showcase`, r * Build your plugin and export the dynamic package -``` +```shell cd ${pluginRootDir} yarn build && yarn run export-dynamic ``` @@ -20,37 +20,37 @@ Once the plugin is built and deployed, it is time to prepare the showcase to run * Run `yarn workspace backend start --inspect` * In logs you should see something like the following: -``` +```text Debugger listening on ws://127.0.0.1:9229/9299bb26-3c32-4781-9488-7759b8781db5 ``` -* The application will be acessible from `http://localhost:7007`. You may start the front end by running the following command from the root directory: `yarn start --filter=app`. It will be available in `http://localhost:3000` -* Attach your IDE debugger to the backend process. This step may depend on the IDE that you are using. For example, if you are using VSCode you may want to check [Node.js debugging in VS Code](https://code.visualstudio.com/docs/nodejs/nodejs-debugging) -* Add Breakpoints to the files in folder `dynamic-plugins-root/${plugin-id}`. Optionally you can configure your IDE to add the source maps for the plugin so you can debug the TypeScript code directly and not the compiled Javascript files +* The application will be accessible from `http://localhost:7007`. You may start the front end by running the following command from the root directory: `yarn start --filter=app`. It will be available in `http://localhost:3000` +* Attach your IDE debugger to the backend process. This step may depend on the IDE that you are using. For example, if you are using VS Code you may want to check [Node.js debugging in VS Code](https://code.visualstudio.com/docs/nodejs/nodejs-debugging) +* Add Breakpoints to the files in folder `dynamic-plugins-root/${plugin-id}`. Optionally you can configure your IDE to add the source maps for the plugin so you can debug the TypeScript code directly and not the compiled JavaScript files ## Backend Dynamic Plugins Container Debug -It is possible to run RHDH on a container and debug plugins that are running on it. In this case you don't need to clone the `backstage-showcase` code locally, instead you must make sure that the running container has the [Node JS debug](https://nodejs.org/en/learn/getting-started/debugging) port open and exposed to the host machine. These are the steps to debug backend dynamic plugins on a container: +It is possible to run RHDH on a container and debug plugins that are running on it. In this case you don't need to clone the `backstage-showcase` code locally, instead you must make sure that the running container has the [Node.js debug](https://nodejs.org/en/learn/getting-started/debugging) port open and exposed to the host machine. These are the steps to debug backend dynamic plugins on a container: * Create directory `dynamic-plugins-root` * Build your plugin and copy the folder `dist-dynamic` to `dynamic-plugins-root` -``` -$ yarn build && yarn export-dynamic -$ cp ${yourPluginRootDir}/dist-dynamic ./dynamic-plugins-root/${pluginID} +```shell +yarn build && yarn export-dynamic +cp ${yourPluginRootDir}/dist-dynamic ./dynamic-plugins-root/${pluginID} ``` -* Start the container and make sure to share the plugins directory with it, allow inspect and open the debug port. Here's a sample command tested on RHDH container image version 1.3: +* Start the container and make sure to share the plugins directory with it, allow inspection and open the debug port. Here's a sample command tested on RHDH container image version 1.3: -``` +```shell podman run \ - -v ./dynamic-plugins-root:/opt/app-root/src/dynamic-plugins-root:Z \ - -v ./app-config.local.yaml:/opt/app-root/src/app-config.local.yaml:Z \ - -p 7007:7007 \ - -p 9229:9229 \ - -e NODE_OPTIONS=--no-node-snapshot \ - --entrypoint='["node", "--inspect=0.0.0.0:9229", "packages/backend", "--config", "app-config.yaml", "--config", "app-config.example.yaml", "--config", "app-config.local.yaml"]' \ - quay.io/rhdh/rhdh-hub-rhel9:1.3 + -v ./dynamic-plugins-root:/opt/app-root/src/dynamic-plugins-root:Z \ + -v ./app-config.local.yaml:/opt/app-root/src/app-config.local.yaml:Z \ + -p 7007:7007 \ + -p 9229:9229 \ + -e NODE_OPTIONS=--no-node-snapshot \ + --entrypoint='["node", "--inspect=0.0.0.0:9229", "packages/backend", "--config", "app-config.yaml", "--config", "app-config.example.yaml", "--config", "app-config.local.yaml"]' \ + quay.io/rhdh/rhdh-hub-rhel9:1.3 ``` You should be able to debug from your IDE by attaching it to the process running on port `9229` or selecting it from a list of processes detected by the IDE. diff --git a/docs/dynamic-plugins/export-derived-package.md b/docs/dynamic-plugins/export-derived-package.md index 1abb7bee50..2faeb8f3af 100644 --- a/docs/dynamic-plugins/export-derived-package.md +++ b/docs/dynamic-plugins/export-derived-package.md @@ -1,6 +1,6 @@ # Export Derived Dynamic Plugin Package -In order to be able to use dynamic plugins in the RHDH, they need to be exported as a separate package. Which is than used by the RHDH to load the plugin. +In order to be able to use dynamic plugins in the RHDH, they need to be exported as a separate package. Which is then used by the RHDH to load the plugin. Exporting a dynamic plugin package is a process of creating a new package that contains the plugin code and its dependencies, and is ready to be used as a dynamic plugin in the RHDH. This document describes how to export a dynamic plugin package from an existing Backstage plugin. @@ -50,7 +50,7 @@ The dynamic export mechanism identifies private, non-backstage dependencies, and ### Shared dependencies During the exporting process some dependencies are marked as shared dependencies, and are expected to be provided by the main Backstage application. These dependencies are not bundled in the dynamic plugin package, but are marked as `peerDependencies` in the `package.json` file. -By default all the `@backstage`-scoped packages are considered shared packages. +By default, all the `@backstage`-scoped packages are considered shared packages. Using `--shared-package` flag you can control which packages are considered shared packages. Shared packages are expected to be provided by the main Backstage application, and are not bundled in the dynamic plugin package. @@ -67,7 +67,7 @@ By default, all packages with `-node` or `-common` suffix are automatically embe Using `--embed-package` flag you can control which packages are embedded in the dynamic plugin package. The `--embed-package` flag can be used multiple times to specify multiple embedded packages. -If plugin depends on another package that is in the same monorepo workspace and it doesn't follow stadart naming convention (`-node`, or `-common`), you can use the `--embed-package` flag to embed it in the dynamic plugin package. +If a plugin depends on another package in the same monorepo workspace, and it doesn't follow standard naming convention (`-node`, or `-common`), you can use the `--embed-package` flag to embed it in the dynamic plugin package. Example of exporting a dynamic plugin with shared and embedded packages: @@ -95,7 +95,7 @@ Our CLI can generate the default configuration for Scalprum on the fly. For gene //TODO document how to use a separate file for the Scalprum configuration which should be a preferred way to customize Scalprum's behavior. -However if you want to customize Scalprum's behavior, you can do so by including additional section to the `package.json` under `scalprum` key: +However, if you want to customize Scalprum's behavior, you can do so by including additional section to the `package.json` under `scalprum` key: ```json ... @@ -111,7 +111,7 @@ However if you want to customize Scalprum's behavior, you can do so by including ... ``` -Dynamic plugins may also need to adopt to specific Backstage needs like static JSX children for mountpoints and dynamic routes. These changes are strictly optional and exported symbols are incompatible with static plugins. +Dynamic plugins may also need to be adopted to specific Backstage needs like static JSX children for mount points and dynamic routes. These changes are strictly optional and exported symbols are incompatible with static plugins. To include static JSX as element children with your dynamically imported component, please define an additional export as follows and use that as your dynamic plugin `importName`: diff --git a/docs/dynamic-plugins/frontend-plugin-wiring.md b/docs/dynamic-plugins/frontend-plugin-wiring.md index 4f21e080b7..7ba89d909d 100644 --- a/docs/dynamic-plugins/frontend-plugin-wiring.md +++ b/docs/dynamic-plugins/frontend-plugin-wiring.md @@ -31,7 +31,7 @@ plugins: ## Extend internal library of available icons -Backstage offers an internal catalog of system icons available across the application. This is traditionally used within Catalog items as icons for links for example. Dynamic plugins also use this catalog when fetching icons for [dynamically configured routes with sidebar navigation menu entry](#dynamic-routes). Therefore if a plugin requires a custom icon to be used for menu item, this icon must be added to the internal icon catalog. This is done via `appIcons` configuration: +Backstage offers an internal catalog of system icons available across the application. This is traditionally used within Catalog items as icons for links for example. Dynamic plugins also use this catalog when fetching icons for [dynamically configured routes with sidebar navigation menu entry](#dynamic-routes). Therefore, if a plugin requires a custom icon to be used for menu item, this icon must be added to the internal icon catalog. This is done via `appIcons` configuration: ```yaml # dynamic-plugins-config.yaml @@ -76,7 +76,7 @@ Traditionally, [Backstage full page extensions](https://backstage.io/docs/plugin This change is usually coupled with an extension to the main sidebar navigation, achieved by editing `packages/app/src/components/Root/Root.tsx`. -In dynamic plugins this mechanism has changed and users are no longer allowed to edit `.tsx` files. Instead they declare their desire to expose additional routes within dynamic plugin configuration: +In dynamic plugins this mechanism has changed and users are no longer allowed to edit `.tsx` files. Instead, they declare their desire to expose additional routes within dynamic plugin configuration: ```yaml # dynamic-plugins-config.yaml @@ -100,16 +100,16 @@ plugins: Each plugin can expose multiple routes and each route is required to define its `path` and `importName` (if it differs from the default export). -- `path` - Unique path in the app. Cannot override existing routes with the exception of the `/` home route: the main home page can be replaced via the dynamic plugins mechanism. +- `path` - Unique path in the app. Cannot override existing routes except the `/` home route: the main home page can be replaced via the dynamic plugins mechanism. - `module` - Optional. Since dynamic plugins can expose multiple distinct modules, you may need to specify which set of assets you want to access within the plugin. If not provided, the default module named `PluginRoot` is used. This is the same as the key in `scalprum.exposedModules` key in plugin's `package.json`. - `importName` - Optional. The actual component name that should be rendered as a standalone page. If not specified the `default` export is used. - `menuItem` - This property allows users to extend the main sidebar navigation and point to their new route. It accepts the following properties: - `text`: The label shown to the user - `icon`: refers to a Backstage system icon name. See [Backstage system icons](https://backstage.io/docs/getting-started/app-custom-theme/#icons) for the list of default icons and [Extending Icons Library](#extend-internal-library-of-available-icons) to extend this with dynamic plugins. - - `importName`: optional name of an exported SidebarItem component. The component will receive a `to` property as well as any properties specified in `config.props` + - `importName`: optional name of an exported `SidebarItem` component. The component will receive a `to` property as well as any properties specified in `config.props` - `config` - An optional field which is a holder to pass `props` to a custom sidebar item -A custom SidebarItem offers opportunities to provide a richer user experience such as notification badges. The component should accept the following properties: +A custom `SidebarItem` offers opportunities to provide a richer user experience such as notification badges. The component should accept the following properties: ```typescript export type MySidebarItemProps = { @@ -119,7 +119,7 @@ export type MySidebarItemProps = { Other properties can be specified as well and configured using the `config.props` property on the dynamic route. -Here is an example configuration specifying a custom SidebarItem component: +Here is an example configuration specifying a custom `SidebarItem` component: ```yaml # dynamic-plugins-config.yaml @@ -163,7 +163,7 @@ plugins: Up to 3 levels of nested menu items are supported. -- - A unique name in the main sidebar navigation. This can represent either a standalone menu item or a parent menu item. If it represents a plugin menu item, the name must match the corresponding path in `dynamicRoutes`. For example, if dynamicRoutes defines `path: /my-plugin`, the `menu_item_name` must be `my-plugin`. +- - A unique name in the main sidebar navigation. This can represent either a standalone menu item or a parent menu item. If it represents a plugin menu item, the name must match the corresponding path in `dynamicRoutes`. For example, if `dynamicRoutes` defines `path: /my-plugin`, the `menu_item_name` must be `my-plugin`. - Handling Complex Paths: - For simple paths like `path: /my-plugin`, the `menu_item_name` should be `my-plugin`. @@ -287,7 +287,7 @@ The following mount points are available: | `search.page.filters` | Search filters | YES, default catalog kind and lifecycle filters are visible | | `search.page.results` | Search results content | YES, default catalog search is present | -Mount points within Catalog aka `entity.page.*` are rendered as tabs. They become visible only if at least one plugin contributes to them or they can render static content (see column 3 in previous table). +Mount points within Catalog aka `entity.page.*` are rendered as tabs. They become visible only if at least one plugin contributes to them, or they can render static content (see column 3 in previous table). Each `entity.page.*` mount point has 2 complementary variations: @@ -337,7 +337,7 @@ Each mount point supports additional configuration: - `isKind`: Accepts a string or a list of string with entity kinds. For example `isKind: component` will render the component only for entity of `kind: Component`. - `isType`: Accepts a string or a list of string with entity types. For example `isType: service` will render the component only for entities of `spec.type: 'service'`. - `hasAnnotation`: Accepts a string or a list of string with annotation keys. For example `hasAnnotation: my-annotation` will render the component only for entities that have `metadata.annotations['my-annotation']` defined. - - condition imported from the plugin's `module`: Must be function name exported from the same `module` within the plugin. For example `isMyPluginAvailable` will render the component only if `isMyPluginAvailable` function returns `true`. The function must have following signature: `(e: Entity) => boolean` + - Condition imported from the plugin's `module`: Must be function name exported from the same `module` within the plugin. For example `isMyPluginAvailable` will render the component only if `isMyPluginAvailable` function returns `true`. The function must have the following signature: `(e: Entity) => boolean` The entity page also supports adding more items to the context menu at the top right of the page. Components targeting the `entity.context.menu` mount point have some constraints to follow. The exported component should be some form of dialog wrapper component that accepts an `open` boolean property and an `onClose` event handler property, like so: @@ -427,10 +427,10 @@ The visibility of a tab is derived from the kind of entity that is being display ### Provide additional Utility APIs -Backstage offers an Utility API mechanism that provide ways for plugins to communicate during their entire life cycle. Utility APIs are registered as: +Backstage offers a Utility API mechanism that provide ways for plugins to communicate during their entire life cycle. Utility APIs are registered as: - Core APIs, which are always present in any Backstage application -- Custom plugin-made API that can be already self contained within any plugin (including dynamic plugins) +- Custom plugin-made API that can be already self-contained within any plugin (including dynamic plugins) - [App API implementations and overrides](https://backstage.io/docs/api/utility-apis/#app-apis) which needs to be added separately. and a plugin can potentially expose multiple API Factories. Dynamic plugins allow a couple different ways to take advantage of this functionality. @@ -444,7 +444,7 @@ dynamicPlugins: my-dynamic-plugin-package-with-api-factories: {} ``` -However if the dynamic plugin doesn't export it's plugin object then it will be necessary to explicitly configure each API factory that should be registered with the `createApp` API via the `apiFactories` configuration: +However, if the dynamic plugin doesn't export it's plugin object then it will be necessary to explicitly configure each API factory that should be registered with the `createApp` API via the `apiFactories` configuration: ```yaml # app-config.yaml @@ -485,7 +485,7 @@ dynamicPlugins: - importName: customScmAuthApiFactory ``` -which would override the default ScmAuth API factory that DeveloperHub defaults to. +which would override the default `ScmAuth` API factory that Developer Hub defaults to. ### Provide custom Scaffolder field extensions diff --git a/docs/dynamic-plugins/installing-plugins.md b/docs/dynamic-plugins/installing-plugins.md index 07325b5352..1537dcdae8 100644 --- a/docs/dynamic-plugins/installing-plugins.md +++ b/docs/dynamic-plugins/installing-plugins.md @@ -14,7 +14,7 @@ Plugins are defined in the `plugins` array in the `dynamic-plugin-config.yaml` f ## Dynamic plugins included in the Showcase container image -The showcase container image is pre-loaded with a variety of dynamic plugins, the majority of which are initially disabled due to mandatory configuration requirements. The comprehensive list of these plugins is outlined in the [`dynamic-plugins.default.yaml`](https://github.com/janus-idp/backstage-showcase/blob/main/dynamic-plugins.default.yaml) file. +The showcase container image is preloaded with a variety of dynamic plugins, the majority of which are initially disabled due to mandatory configuration requirements. The comprehensive list of these plugins is outlined in the [`dynamic-plugins.default.yaml`](https://github.com/janus-idp/backstage-showcase/blob/main/dynamic-plugins.default.yaml) file. Upon the application startup, for each plugin disabled by default, the `install-dynamic-plugins` init container within the `backstage` Pod's log will exhibit a line similar to the following: @@ -62,7 +62,7 @@ plugins: For private registries, you can set the `REGISTRY_AUTH_FILE` environment variable to the path of the configuration file containing the authentication details for the registry. This file is typically located at `~/.config/containers/auth.json` or `~/.docker/config.json`. -For integratity check one may use [image digest](https://github.com/opencontainers/image-spec/blob/main/descriptor.md#digests), making it possible to refer to the image diggest in the dynamic plugin package: +For integrity check one may use [image digest](https://github.com/opencontainers/image-spec/blob/main/descriptor.md#digests), making it possible to refer to the image digest in the dynamic plugin package: ```yaml plugins: @@ -100,7 +100,7 @@ npm view --registry https://example.com:4873/ @backstage-community/plugin-todo-d #### Using a custom NPM registry -To configure the NPM registry URL and authentication information, you can utilize a `.npmrc` file. When using OpenShift or Kubernetes, you can add this file by creating a secret with the `.npmrc` file content and mounting it into `install-dynamic-plugins` initContainer. +To configure the NPM registry URL and authentication information, you can utilize a `.npmrc` file. When using OpenShift or Kubernetes, you can add this file by creating a secret with the `.npmrc` file content and mounting it into `install-dynamic-plugins` init container. ```yaml apiVersion: v1 @@ -114,7 +114,7 @@ stringData: //:_authToken= ``` -When using RHDH Helm Chart you can just name the Secret using following pattern `{{ .Release.Name }}-dynamic-plugins-npmrc` and it will be mounted automatically. (If you installed RHDH using `helm install rhdh ....` than the secret should be named `rhdh-dynamic-plugins-npmrc`) +When using RHDH Helm Chart you can just name the Secret using following pattern `{{ .Release.Name }}-dynamic-plugins-npmrc`, and it will be mounted automatically. (If you installed RHDH using `helm install rhdh ....` than the secret should be named `rhdh-dynamic-plugins-npmrc`) When using the Operator .... diff --git a/docs/dynamic-plugins/local.md b/docs/dynamic-plugins/local.md index 420c760bd8..0733617dbe 100644 --- a/docs/dynamic-plugins/local.md +++ b/docs/dynamic-plugins/local.md @@ -36,7 +36,7 @@ backend:start: {"level":"info","message":"Loaded dynamic frontend plugin ' version Plugin has been loaded Plugin will be enabled diff --git a/docs/dynamic-plugins/override-core-services.md b/docs/dynamic-plugins/override-core-services.md index d8b665d460..2bbce73fe6 100644 --- a/docs/dynamic-plugins/override-core-services.md +++ b/docs/dynamic-plugins/override-core-services.md @@ -2,7 +2,7 @@ ## Overview -The Backstage backend platform consists of a number of core services that are well encapsulated. The configuration of these core services is normally done by directly customizing the backend source code and rebuilding. However the dynamic plugin functionality adds the ability for core service customization via installing it as a `BackendFeature`. The Developer Hub backend normally installs all of these default core services statically during initialization. Environment variables can configure the backend to avoid statically installing a given default core service, allowing for dynamic plugin installation. +The Backstage backend platform consists of a number of core services that are well encapsulated. The configuration of these core services is normally done by directly customizing the backend source code and rebuilding. However, the dynamic plugin functionality adds the ability for core service customization via installing it as a `BackendFeature`. The Developer Hub backend normally installs all of these default core services statically during initialization. Environment variables can configure the backend to avoid statically installing a given default core service, allowing for dynamic plugin installation. ## An Example @@ -39,7 +39,6 @@ This `BackendFeature` overrides the default HTTP router service factory. Becaus To allow a dynamic plugin to load a core service override, start the Developer Hub backend with the environment variable set that corresponds with the core service ID to be overridden. Here is a list of the available environment variables and core service IDs: - - `ENABLE_CORE_AUTH_OVERRIDE` - allow overriding the `core.auth` service - `ENABLE_CORE_CACHE_OVERRIDE` - allow overriding the `core.cache` service - `ENABLE_CORE_ROOTCONFIG_OVERRIDE` - allow overriding the `core.rootConfig` service @@ -56,4 +55,4 @@ To allow a dynamic plugin to load a core service override, start the Developer H - `ENABLE_CORE_SCHEDULER_OVERRIDE` - allow overriding the `core.scheduler` service - `ENABLE_CORE_USERINFO_OVERRIDE` - allow overriding the `core.userInfo` service - `ENABLE_CORE_URLREADER_OVERRIDE` - allow overriding the `core.urlReader` service -- `ENABLE_EVENTS_SERVICE_OVERRIDE` - allow overriding the `events.service` service \ No newline at end of file +- `ENABLE_EVENTS_SERVICE_OVERRIDE` - allow overriding the `events.service` service diff --git a/docs/dynamic-plugins/packaging-dynamic-plugins.md b/docs/dynamic-plugins/packaging-dynamic-plugins.md index 00830a3c4c..944175eea2 100644 --- a/docs/dynamic-plugins/packaging-dynamic-plugins.md +++ b/docs/dynamic-plugins/packaging-dynamic-plugins.md @@ -21,7 +21,7 @@ The derived dynamic plugin JavaScript packages should **not** be pushed to the p **Prerequisites:** - `podman` or `docker` installed on your system. -- An exported derived dynamic plugin package (see: [Export Derived Dynamic Plugin Package](export-derived-package.md). +- An exported derived dynamic plugin package (see: [Export Derived Dynamic Plugin Package](export-derived-package.md)). To package the plugin into an OCI image, use the `package package-dynamic-plugins` command from `@janus-idp/cli` in the plugin’s source code root directory (not in the `dist-dynamic` directory). @@ -33,11 +33,11 @@ npx @janus-idp/cli@latest package package-dynamic-plugins --tag quay.io/example/ The `--tag` argument is required when using this packaging method. It specifies the image name and tag. The image won't be pushed to the registry automatically; use the `podman push` or `docker push` command to push the image to the registry. -## Creagin a `tgz` Archive +## Creating a `tgz` Archive **Prerequisites:** -- An exported derived dynamic plugin package (see: [Export Derived Dynamic Plugin Package](export-derived-package.md). +- An exported derived dynamic plugin package (see: [Export Derived Dynamic Plugin Package](export-derived-package.md)). To package the plugin into a `tgz` archive, run the `npm pack` command in the `dist-dynamic` directory. This will create a `tgz` archive in the current directory that can be used to install the plugin. @@ -84,7 +84,7 @@ oc new-app --image-stream=plugin-registry **Prerequisites:** -- An exported derived dynamic plugin package (see: [Export Derived Dynamic Plugin Package](export-derived-package.md). +- An exported derived dynamic plugin package (see: [Export Derived Dynamic Plugin Package](export-derived-package.md)). > [!WARNING] > Using your own internal npm registry to distribute derived dynamic plugin package is recommended. diff --git a/e2e-tests/README.md b/e2e-tests/README.md index 2027d58a01..4e5a946d79 100644 --- a/e2e-tests/README.md +++ b/e2e-tests/README.md @@ -2,14 +2,14 @@ ### How to setup backstage configuration during the pipeline -[configmap-app-config-rhdh.yaml](../.ibm/pipelines/resources/config_map/configmap-app-config-rhdh.yaml) is the +[app-config-rhdh.yaml](../.ibm/pipelines/resources/config_map/app-config-rhdh.yaml) is the configuration file to add plugins or any other kind of configuration into Backstage -### Environment Variables into configmap-app-config-rhdh.yaml +### Environment Variables into app-config-rhdh.yaml To use environment variables -on [configmap-app-config-rhdh.yaml](../.ibm/pipelines/resources/config_map/configmap-app-config-rhdh.yaml) +on [app-config-rhdh.yaml](../.ibm/pipelines/resources/config_map/app-config-rhdh.yaml) we need to set the envs encoded as Base64 in the [secrets-rhdh-secrets.yaml](.ibm/pipelines/auth/secrets-rhdh-secrets.yaml) . You can use temporary values for the secrets because it can be replaced by the pipeline.