Red Hat Developer Hub 1.5

TechDocs for Red Hat Developer Hub

Red Hat Customer Content Services

Abstract

Your organization can use the built-in TechDocs plugin for Red Hat Developer Hub to create, find, and use technical documentation in a central location and in a standardized way. Use supported TechDocs add-ons, or create your own, to further enhance your documentation experience.

1. About TechDocs

The Red Hat Developer Hub instance comes with the TechDocs plugin preinstalled and enabled by default. Your organization can use the TechDocs plugin to create, find, and manage documentation in a central location and in a standardized way. You can also enhance your technical documentation experience with built-in TechDocs features and add-ons. For example:

Docs-like-code approach
Write your technical documentation in Markdown files that are stored inside your project repository along with your code.
Documentation site generation
Use MkDocs to create a full-featured, Markdown-based, static HTML site for your documentation that is rendered centrally in Developer Hub.
Documentation site metadata and integrations
See additional metadata about the documentation site alongside the static documentation, such as the date of the last update, the site owner, top contributors, open GitHub issues, Slack support channels, and Stack Overflow Enterprise tags.
Built-in navigation and search
Locate the information that you need within a document quickly and easily.
Add-ons
Make your documentation more functional and interactive with supported TechDocs add-ons. Some add-ons are preinstalled and enabled by default. To extend the default functionality, you can dynamically load external and third-party add-ons into your Red Hat Developer Hub instance. If you want to further customize your TechDocs experience, you can create add-ons that meet specific documentation needs for your organization.

2. TechDocs configuration

The TechDocs plugin is preinstalled and enabled on a Developer Hub instance by default. You can disable or enable the TechDocs plugin, and change other parameters, by configuring the Red Hat Developer Hub Helm chart or the Red Hat Developer Hub Operator ConfigMap.

Important

Red Hat Developer Hub includes a built-in TechDocs builder that generates static HTML documentation from your codebase. However, the default basic setup of the local builder is not intended for production.

You can use a CI/CD pipeline with the repository that has a dedicated job to generate docs for TechDocs. The generated static files are stored in OpenShift Data Foundation or in a cloud storage solution of your choice and published to a static HTML documentation site.

After you configure OpenShift Data Foundation to store the files that TechDocs generates, you can configure the TechDocs plugin to use the OpenShift Data Foundation for cloud storage.

Additional resources

2.1. Configuring storage for TechDocs files

The TechDocs publisher stores generated files in local storage or in cloud storage, such as OpenShift Data Foundation, Google GCS, AWS S3, or Azure Blob Storage.

2.1.1. Using OpenShift Data Foundation for file storage

You can configure OpenShift Data Foundation to store the files that TechDocs generates instead of relying on other cloud storage solutions.

OpenShift Data Foundation provides an ObjectBucketClaim custom resource (CR) that you can use to request an S3 compatible bucket backend. You must install the OpenShift Data Foundation Operator to use this feature.

Prerequisites

Procedure

  • Create an ObjectBucketClaim CR where the generated TechDocs files are stored. For example:

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <rhdh_bucket_claim_name>
    spec:
      generateBucketName: <rhdh_bucket_claim_name>
      storageClassName: openshift-storage.noobaa.io
    Note

    Creating the Developer Hub ObjectBucketClaim CR automatically creates both the Developer Hub ObjectBucketClaim config map and secret. The config map and secret have the same name as the ObjectBucketClaim CR.

After you create the ObjectBucketClaim CR, you can use the information stored in the config map and secret to make the information accessible to the Developer Hub container as environment variables. Depending on the method that you used to install Developer Hub, you add the access information to either the Red Hat Developer Hub Helm chart or Operator configuration.

Additional resources

2.1.2. Making object storage accessible to containers by using the Helm chart

Creating a ObjectBucketClaim custom resource (CR) automatically generates both the Developer Hub ObjectBucketClaim config map and secret. The config map and secret contain ObjectBucket access information. Adding the access information to the Helm chart configuration makes it accessible to the Developer Hub container by adding the following environment variables to the container:

  • BUCKET_NAME
  • BUCKET_HOST
  • BUCKET_PORT
  • BUCKET_REGION
  • BUCKET_SUBREGION
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

These variables are then used in the TechDocs plugin configuration.

Prerequisites

  • You have installed Red Hat Developer Hub on OpenShift Container Platform using the Helm chart.
  • You have created an ObjectBucketClaim CR for storing files generated by TechDocs. For more information see Using OpenShift Data Foundation for file storage

Procedure

  • In the upstream.backstage key in the Helm chart values, enter the name of the Developer Hub ObjectBucketClaim secret as the value for the extraEnvVarsSecrets field and the extraEnvVarsCM field. For example:

    upstream:
      backstage:
        extraEnvVarsSecrets:
          - <rhdh_bucket_claim_name>
        extraEnvVarsCM:
          - <rhdh_bucket_claim_name>
2.1.2.1. Example TechDocs Plugin configuration for the Helm chart

The following example shows a Developer Hub Helm chart configuration for the TechDocs plugin:

global:
  dynamic:
    includes:
      - 'dynamic-plugins.default.yaml'
  plugins:
    - disabled: false
      package: ./dynamic-plugins/dist/backstage-plugin-techdocs-backend-dynamic
      pluginConfig:
        techdocs:
          builder: external
          generator:
            runIn: local
          publisher:
            awsS3:
              bucketName: '${BUCKET_NAME}'
              credentials:
                accessKeyId: '${AWS_ACCESS_KEY_ID}'
                secretAccessKey: '${AWS_SECRET_ACCESS_KEY}'
              endpoint: 'https://${BUCKET_HOST}'
              region: '${BUCKET_REGION}'
              s3ForcePathStyle: true
            type: awsS3

2.1.3. Making object storage accessible to containers by using the Operator

Creating a ObjectBucketClaim custom resource (CR) automatically generates both the Developer Hub ObjectBucketClaim config map and secret. The config map and secret contain ObjectBucket access information. Adding the access information to the Operator configuration makes it accessible to the Developer Hub container by adding the following environment variables to the container:

  • BUCKET_NAME
  • BUCKET_HOST
  • BUCKET_PORT
  • BUCKET_REGION
  • BUCKET_SUBREGION
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

These variables are then used in the TechDocs plugin configuration.

Prerequisites

  • You have installed Red Hat Developer Hub on OpenShift Container Platform using the Operator.
  • You have created an ObjectBucketClaim CR for storing files generated by TechDocs.

Procedure

  • In your Backstage CR, enter the name of the Developer Hub ObjectBucketClaim config map as the value for the spec.application.extraEnvs.configMaps field and enter the Developer Hub ObjectBucketClaim secret name as the value for the spec.application.extraEnvs.secrets field. For example:

    apiVersion: objectbucket.io/v1alpha1
    kind: Backstage
    metadata:
     name: <name>
    spec:
      application:
        extraEnvs:
          configMaps:
            - name: <rhdh_bucket_claim_name>
          secrets:
            - name: <rhdh_bucket_claim_name>
2.1.3.1. Example TechDocs Plugin configuration for the Operator

The following example shows a Red Hat Developer Hub Operator config map configuration for the TechDocs plugin:

kind: ConfigMap
apiVersion: v1
metadata:
  name: dynamic-plugins-rhdh
data:
  dynamic-plugins.yaml: |
    includes:
      - dynamic-plugins.default.yaml
    plugins:
      - disabled: false
        package: ./dynamic-plugins/dist/backstage-plugin-techdocs-backend-dynamic
        pluginConfig:
          techdocs:
            builder: external
            generator:
              runIn: local
            publisher:
              awsS3:
                bucketName: '${BUCKET_NAME}'
                credentials:
                  accessKeyId: '${AWS_ACCESS_KEY_ID}'
                  secretAccessKey: '${AWS_SECRET_ACCESS_KEY}'
                endpoint: 'https://${BUCKET_HOST}'
                region: '${BUCKET_REGION}'
                s3ForcePathStyle: true
              type: awsS3

2.2. Configuring CI/CD to generate and publish TechDocs sites

TechDocs reads the static generated documentation files from a cloud storage bucket, such as OpenShift Data Foundation. The documentation site is generated on the CI/CD workflow associated with the repository containing the documentation files. You can generate docs on CI and publish to a cloud storage using the techdocs-cli CLI tool.

You can use the following example to create a script for TechDocs publication:

# Prepare
REPOSITORY_URL='https://github.com/org/repo'
git clone $REPOSITORY_URL
cd repo

# Install @techdocs/cli, mkdocs and mkdocs plugins
npm install -g @techdocs/cli
pip install "mkdocs-techdocs-core==1.*"

# Generate
techdocs-cli generate --no-docker

# Publish
techdocs-cli publish --publisher-type awsS3 --storage-name <bucket/container> --entity <Namespace/Kind/Name>

The TechDocs workflow starts the CI when a user makes changes in the repository containing the documentation files. You can configure the workflow to start only when files inside the docs/ directory or mkdocs.yml are changed.

2.2.1. Preparing your repository for CI

The first step on the CI is to clone your documentation source repository in a working directory.

Procedure

  • To clone your documentation source repository in a working directory, enter the following command:

    git clone <https://path/to/docs-repository/>

2.2.2. Generating the TechDocs site

Procedure

To configure CI/CD to generate your techdocs, complete the following steps:

  1. Install the npx package to run techdocs-cli using the following command:

    npm install -g npx
  2. Install the techdocs-cli tool using the following command:

    npm install -g @techdocs/cli
  3. Install the mkdocs plugins using the following command:

    pip install "mkdocs-techdocs-core==1.*"
  4. Generate your techdocs site using the following command:

    npx @techdocs/cli generate --no-docker --source-dir <path_to_repo> --output-dir ./site

    Where <path_to_repo> is the location in the file path that you used to clone your repository.

2.2.3. Publishing the TechDocs site

Procedure

To publish your techdocs site, complete the following steps:

  1. Set the necessary authentication environment variables for your cloud storage provider.
  2. Publish your techdocs using the following command:

    npx @techdocs/cli publish --publisher-type <awsS3|googleGcs> --storage-name <bucket/container> --entity <namespace/kind/name> --directory ./site
  3. Add a .github/workflows/techdocs.yml file in your Software Template(s). For example:

    name: Publish TechDocs Site
    
    on:
     push:
       branches: [main]
       # You can even set it to run only when TechDocs related files are updated.
       # paths:
       #   - "docs/**"
       #   - "mkdocs.yml"
    
    jobs:
     publish-techdocs-site:
       runs-on: ubuntu-latest
    
       # The following secrets are required in your CI environment for publishing files to AWS S3.
       # e.g. You can use GitHub Organization secrets to set them for all existing and new repositories.
       env:
         TECHDOCS_S3_BUCKET_NAME: ${{ secrets.TECHDOCS_S3_BUCKET_NAME }}
         AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
         AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
         AWS_REGION: ${{ secrets.AWS_REGION }}
         ENTITY_NAMESPACE: 'default'
         ENTITY_KIND: 'Component'
         ENTITY_NAME: 'my-doc-entity'
         # In a Software template, Scaffolder will replace {{cookiecutter.component_id | jsonify}}
         # with the correct entity name. This is same as metadata.name in the entity's catalog-info.yaml
         # ENTITY_NAME: '{{ cookiecutter.component_id | jsonify }}'
    
       steps:
         - name: Checkout code
           uses: actions/checkout@v3
    
         - uses: actions/setup-node@v3
         - uses: actions/setup-python@v4
           with:
             python-version: '3.9'
    
         - name: Install techdocs-cli
           run: sudo npm install -g @techdocs/cli
    
         - name: Install mkdocs and mkdocs plugins
           run: python -m pip install mkdocs-techdocs-core==1.*
    
         - name: Generate docs site
           run: techdocs-cli generate --no-docker --verbose
    
         - name: Publish docs site
           run: techdocs-cli publish --publisher-type awsS3 --storage-name $TECHDOCS_S3_BUCKET_NAME --entity $ENTITY_NAMESPACE/$ENTITY_KIND/$ENTITY_NAME

3. TechDocs add-ons

TechDocs add-ons are dynamic plugins that extend the functionality of the built-in TechDocs plugin. For example, you can use add-ons to report documentation issues, change text size, or view images in overlay in either the TechDocs Reader page or an Entity page.

The following table describes the TechDocs add-ons that are available for Red Hat Developer Hub 1.5:

Table 1. TechDocs Add-ons available in Red Hat Developer Hub

TechDocs Add-onPackage/PluginDescriptionType

<ReportIssue />

backstage-plugin-techdocs-module-addons-contrib

Select a portion of text on a TechDocs page and open an issue against the repository that contains the documentation. The issue template is automatically populated with the selected text.

Preinstalled

<TextSize />

backstage-plugin-techdocs-module-addons-contrib

Customize text size on documentation pages by increasing or decreasing the font size with a slider or buttons. The default value for font size is 100% and this setting is kept in the browser’s local storage whenever it is changed.

External

<LightBox />

backstage-plugin-techdocs-module-addons-contrib

Open images in a light-box on documentation pages, to navigate to multiple images on a single page. The image size of the light-box image is the same as the image size on the document page. Clicking the zoom icon increases the image size to fit the screen.

External

You can use a dynamic plugin to import a TechDocs add-on. TechDocs add-ons are enabled at the plugin level, therefore, enabling a plugin enables all of the TechDocs add-ons in the specified plugin package. The preinstalled and external add-ons supported by {company} are imported by the backstage-plugin-techdocs-module-addons-contrib plugin package. Since the disabled status is set at the plugin level, the disabled status of the plugin package applies to all of the TechDocs add-ons imported by that package.

3.1. Installing and configuring a TechDocs add-on

TechDocs add-ons are supported by Red Hat are imported by the backstage-plugin-techdocs-module-addons-contrib plugin package. The <ReportIssue /> add-on is preinstalled in the TechDocs plugin and enabled by default. You can install external TechDocs add-ons by adding them to backstage-plugin-techdocs-module-addons-contrib package with either the Red Hat Developer Hub Operator or Helm chart. Additionally, you can import compatible third-party add-ons, including add-ons that you create yourself, with a third-party dynamic plugin.

3.1.1. Installing and configuring an external TechDocs add-on using the Operator

You can use a dynamic plugin to import TechDocs add-ons into your TechDocs plugin. If you use the Red Hat Developer Hub Operator to install the dynamic plugin, you can add TechDocs add-ons to the plugin package in your ConfigMap.

Preinstalled add-ons, such as ReportIssue, are included in the default backstage-plugin-techdocs-module-addons-contrib package configuration. External add-ons that are supported by Red Hat are installed by manually adding them to the techdocsAddons section of the configuration file.

Procedure

  1. From the Developer perspective in the OpenShift Container Platform web console, click ConfigMaps > Create ConfigMap.
  2. From the Create ConfigMap page, select the YAML view option in the Configure via field.
  3. In the newly created ConfigMap, add the default backstage-plugin-techdocs-module-addons-contrib package configuration. For example:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: dynamic-plugins-rhdh
    data:
      dynamic-plugins.yaml: |
        includes:
          - dynamic-plugins.default.yaml
        plugins:
          - package: ./dynamic-plugins/dist/backstage-plugin-techdocs-module-addons-contrib
            disabled: false
            pluginConfig:
              dynamicPlugins:
                frontend:
                  backstage.plugin-techdocs-module-addons-contrib:
                    techdocsAddons:
                      - importName: ReportIssue
  4. In the techdocsAddons section of the ConfigMap, add importName: <external_techdocs_add-on> for each external TechDocs add-on that you want to add from the specified plugin package. For example:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: dynamic-plugins-rhdh
    data:
      dynamic-plugins.yaml: |
        includes:
          - dynamic-plugins.default.yaml
        plugins:
          - package: ./dynamic-plugins/dist/backstage-plugin-techdocs-module-addons-contrib
            disabled: false
            pluginConfig:
              dynamicPlugins:
                frontend:
                  backstage.plugin-techdocs-module-addons-contrib:
                    techdocsAddons:
                      - importName: ReportIssue
                      - importName: <external_techdocs_add-on>

    where:

    <external_techdocs_add-on>
    Specifies the external TechDocs add-on that you want to install, for example, TextSize or LightBox.
  5. Click Create.
  6. In the web console navigation menu, click Topology.
  7. Click on the overflow menu for the Red Hat Developer Hub instance that you want to use and select Edit Backstage to load the YAML view of the Red Hat Developer Hub instance.
  8. In your Backstage CR, add the dynamicPluginsConfigMapName: <dynamic_plugins_configmap> key-value pair. For example:

    apiVersion: rhdh.redhat.com/v1alpha3
    kind: Backstage
    metadata:
      name: my-rhdh
    spec:
      application:
    # ...
        dynamicPluginsConfigMapName: _<dynamic_plugins_configmap>_
    # ...

    where:

    <dynamic_plugins_configmap>
    Specifies the name of your dynamic plugins ConfigMap for your Red Hat Developer Hub instance, for example, dynamic-plugins-rhdh.
  9. Click Save.
  10. In the web console navigation menu, click Topology and wait for the Red Hat Developer Hub pod to start.
  11. Click the Open URL icon to start using the Red Hat Developer Hub platform with the new configuration changes.

3.1.2. Installing and configuring an external TechDocs add-on using the Helm chart

You can use a dynamic plugin to import TechDocs add-ons into your TechDocs plugin. If you use the Red Hat Developer Hub Helm chart to install the dynamic plugin, you can add TechDocs add-ons to the plugin package in your Helm chart.

Preinstalled add-ons, such as ReportIssue, are included in the default backstage-plugin-techdocs-module-addons-contrib package configuration. External add-ons that are supported by Red Hat are installed by manually adding them to the techdocsAddons section of the configuration file.

Prerequisites

  • The TechDocs plugin is installed and enabled.

Procedure

  1. In your Helm chart, add the global.dynamic parameters required to install a dynamic plugin, as shown in Installing dynamic plugins using the Helm chart

    Note

    The default configuration includes the dynamic-plugins.default.yaml file, which contains all of the dynamic plugins, including TechDocs add-ons, that are preinstalled in Red Hat Developer Hub, whether they are enabled or disabled by default.

  2. In your Helm chart, add the default backstage-plugin-techdocs-module-addons-contrib package configuration. For example:

    global:
      dynamic:
        plugins:
          - package: ./dynamic-plugins/dist/backstage-plugin-techdocs-module-addons-contrib
            disabled: false
            pluginConfig:
              dynamicPlugins:
                frontend:
                  backstage.plugin-techdocs-module-addons-contrib:
                    techdocsAddons:
                      - importName: ReportIssue
  3. In the techdocsAddons section of the Helm chart, add importName: <external_techdocs_add-on> for each external TechDocs add-on that you want to add from the specified plugin package. For example:

    global:
      dynamic:
        plugins:
          - package: ./dynamic-plugins/dist/backstage-plugin-techdocs-module-addons-contrib
            disabled: false
            pluginConfig:
              dynamicPlugins:
                frontend:
                  backstage.plugin-techdocs-module-addons-contrib:
                    techdocsAddons:
                      - importName: ReportIssue
                      - importName: <external_techdocs_add-on>

    where:

    <external_techdocs_add-on>
    Specifies the external TechDocs add-on that you want to install, for example, TextSize or LightBox.

3.1.3. Installing and configuring a third-party TechDocs add-on

You can install compatible third-party TechDocs add-on on your Red Hat Developer Hub instance as a front-end dynamic plugin.

Prerequisites

  • The third-party TechDocs add-on has a valid package.json file in its root directory, containing all required metadata and dependencies.
  • The third-party plugin is packaged as a dynamic plugin in an OCI image. For alternative package types, see Installing third-party plugins in Red Hat Developer Hub.
  • You have installed the yarn package manager.
  • The third-party plugin is packaged as a dynamic plugin in an OCI image.* You have installed and configured Node.js and NPM.

Procedure

  1. Install the third-party plugin that you want to use to import your third-party add-on by entering the following command:

    yarn install
  2. Obtain the source code for the third-party TechDocs add-on that you want to use.
  3. Export the TechDocs add-on as a dynamic plugin using the following command:

    npx @janus-idp/cli@latest package export-dynamic-plugin
    Note

    The @latest tag pulls the latest version of the @janus-idp/cli package, which is compatible with the most recent features and fixes. Use a version that is compatible with your Red Hat Developer Hub version.

  4. To package the third-party TechDocs add-on as a dynamic plugin, navigate to the root directory where the plugin is stored (not the dist-dynamic directory) and run the npx command with the --tag option to specify the image name and tag. For example:

    npx @janus-idp/cli@latest package package-dynamic-plugins --tag quay.io/<user_name>/<techdocs_add-on_image>:latest
    Note

    The output of the package-dynamic-plugins command provides the file path to the plugin for use in the dynamic-plugin-config.yaml file.

  5. To publish the third-party TechDocs add-on to a Quay repository, push the image to a registry using one of the following commands, depending on your virtualization tool:

    • To use podman, enter the following command:

      podman push quay.io/<user_name>/<techdocs_add-on_image>:latest
    • To use docker, enter the following command:

      docker push quay.io/<user_name>/<techdocs_add-on_image>:latest
  6. Open your dynamic-plugins.yaml file to view or modify the configuration for the third-party TechDocs add-on. For example:

    plugins:
          - package: oci://quay.io/<user_name>/<techdocs_add-on_image>:latest!<techdocs_add-on_package>
            disabled: false
            pluginConfig:
              dynamicPlugins:
                frontend:
                 <techdocs_add-on_package>
                    techdocsAddons:
                      - importName: <third-party_add-on_name>
                       config:
                          props:
                           <techdocs_add-on_property_key>: <techdocs_add-on_property_value>

    where

    <user_name>
    Specifies your Quay user name or organization name.
    <techdocs_add-on_image>
    Specifies the name of the image for the third-party add-on that you want to use, for example, mermaid.
    <techdocs_add-on_package>
    Specifies the , for example, backstage-plugin-techdocs-addon-mermaid.
    <third-party_add-on_name>
    Specifies the name of the third-party add-on that you want to use, for example, Mermaid.
    <techdocs_add-on_property_key>
    Specifies the name of the custom property that can be passed to the third-party add-on, for example, themeVariables. Properties are specific to each add-on. You can list multiple properties for an add-on.
    <techdocs_add-on_property_value>
    Specifies the value of a property key for the third-party add-on, for example, lineColor: #000000.

3.2. Removing a TechDocs add-on

Administrators can remove installed TechDocs add-ons from your Red Hat Developer Hub instance by using either the Operator or Helm chart, depending on the method used to install the add-on. If you used the Operator to install the add-on, remove it from the ConfigMap. If you used the Helm chart to install the add-on, remove it from the Helm chart.

If you want to disable a plugin instead of removing it from your Red Hat Developer Hub instance, you can disable the plugin that you are using to import the TechDocs add-on. Since the disabled status is controlled at the plugin level, disabling the plugin disables all of the TechDocs add-ons in the specified plugin package.

3.2.1. Removing an external TechDocs add-on from your ConfigMap

If you no longer want to use the functionality of a TechDocs add-on that is imported from a particular plugin that you installed on your Red Hat Developer Hub instance with the Operator, you can temporarily disable it or permanently remove it from your ConfigMap. The disabled status is controlled at the plugin level, therefore, disabling the plugin disables all of the TechDocs add-ons in the disabled plugin package.

Procedure

  1. From the Developer perspective in the OpenShift Container Platform web console, click ConfigMaps.
  2. From the ConfigMaps page, click the ConfigMap that contains the TechDocs add-on that you want to remove.
  3. Select the YAML view option in the Configure via field.
  4. In the plugins section of the ConfigMap, do one of the following actions based on whether you want to disable or remove a TechDocs add-on:

    • To temporarily disable all of the TechDocs add-ons in a particular plugin package, change the value of the disabled field to true. For example:

      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: dynamic-plugins-rhdh
      data:
        dynamic-plugins.yaml: |
          includes:
            - dynamic-plugins.default.yaml
          plugins:
            - package: ./dynamic-plugins/dist/backstage-plugin-techdocs-module-addons-contrib
              disabled: true
              pluginConfig:
                dynamicPlugins:
                  frontend:
                    backstage.plugin-techdocs-module-addons-contrib:
                      techdocsAddons:
                        - importName: ReportIssue
                        - importName: <external_techdocs_add-on>

      where:

      <external_techdocs_add-on>
      Specifies the external TechDocs add-on that you want to remove, for example, TextSize.
    • To remove one or more TechDocs add-ons from your Red Hat Developer Hub instance, delete importName: <external_techdocs_add-on> for each external TechDocs add-on that you want to remove from the techdocsAddons section of your ConfigMap. For example:

      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: dynamic-plugins-rhdh
      data:
        dynamic-plugins.yaml: |
          includes:
            - dynamic-plugins.default.yaml
          plugins:
            - package: ./dynamic-plugins/dist/backstage-plugin-techdocs-module-addons-contrib
              disabled: false
              pluginConfig:
                dynamicPlugins:
                  frontend:
                    backstage.plugin-techdocs-module-addons-contrib:
                      techdocsAddons:
                        - importName: ReportIssue
                        - importName: <external_techdocs_add-on>

      where:

      <external_techdocs_add-on>
      Specifies the external TechDocs add-on that you want to remove, for example, TextSize.
  5. Click Save.
  6. In the web console navigation menu, click Topology and wait for the Red Hat Developer Hub pod to start.
  7. Click the Open URL icon to start using the Red Hat Developer Hub platform with the new configuration changes.

3.2.2. Removing an external TechDocs add-on from your Helm chart

If you no longer want to use the functionality of a TechDocs add-on that is imported from a particular plugin that you installed on your Red Hat Developer Hub instance with the Helm chart, you can temporarily disable it or permanently remove it from your Helm chart. The disabled status is controlled at the plugin level, therefore, disabling the plugin disables all of the TechDocs add-ons in the disabled plugin package.

Procedure

  • In the plugins section of the Helm chart, do one of the following actions based on whether you want to disable or remove a TechDocs add-on:

    • To temporarily disable all of the TechDocs add-ons in a particular plugin package, change the value of the disabled field to true. For example:

      global:
        dynamic:
          plugins:
            - package: ./dynamic-plugins/dist/backstage-plugin-techdocs-module-addons-contrib
              disabled: true
              pluginConfig:
                dynamicPlugins:
                  frontend:
                    backstage.plugin-techdocs-module-addons-contrib:
                      techdocsAddons:
                        - importName: ReportIssue
                        - importName: <external_techdocs_add-on>

      where:

      <external_techdocs_add-on>
      Specifies the external TechDocs add-on that you want to remove, for example, TextSize.
    • To remove one or more TechDocs add-ons from your Red Hat Developer Hub instance, delete importName: <external_techdocs_add-on> for each external TechDocs add-on that you want to remove from the techdocsAddons section of your Helm chart. For example:

      global:
        dynamic:
          plugins:
            - package: ./dynamic-plugins/dist/backstage-plugin-techdocs-module-addons-contrib
              disabled: false
              pluginConfig:
                dynamicPlugins:
                  frontend:
                    backstage.plugin-techdocs-module-addons-contrib:
                      techdocsAddons:
                        - importName: ReportIssue
                        - importName: <external_techdocs_add-on>

      where:

      <external_techdocs_add-on>
      Specifies the external TechDocs add-on that you want to remove, for example, TextSize.

3.3. Using TechDocs add-ons

After an administrator installs a TechDocs add-on in your Red Hat Developer Hub instance, you can use it to extend the functionality of the TechDocs plugin and enhance your documentation experience.

3.3.1. Using the ReportIssue TechDocs add-on

If you find an error in your organization’s TechDocs documentation, you can use the ReportIssue add-on to open a new GitHub or GitLab issue directly from the documentation. ReportIssue automatically imports the text that you highlight in the document into a new issue template in your repository.

Prerequisites

  • The ReportIssue add-on is installed and enabled in your TechDocs plugin.
  • You have permissions to create issues in the repository where documentation issues are reported.

Procedure

  1. In your TechDocs documentation, highlight the text that you want to report an issue for.
  2. Click the text in the ReportIssue box, for example, Open new GitHub issue.
  3. From the new issue page in your repository, use the template to create the issue that you want to report.

    Note

    The default issue title is Documentation feedback: <highlighted_text>, where <highlighted_text> is the text that you highlighted in your TechDocs documentation.

    In the issue description, <highlighted_text> is the default value for the The highlighted text field.

Verification

  • The issue that you created is listed on the issues page in your repository.

3.3.2. Using the TextSize TechDocs add-on

You can use the TextSize add-on to change the size of the text on either the TechDocs Reader page or an Entity page.

Prerequisites

  • The TextSize add-on is installed and enabled in your TechDocs plugin.

Procedure

  1. In your TechDocs header, click the Settings icon.
  2. Use the sliding scale to adjust the size of your documentation text.

    Note
    • The default text size is 100%
    • The minimize text size is 90%
    • The maximum text size is 150%

3.3.3. Using the LightBox TechDocs add-on

If your TechDocs documentation contains an image, you can use the LightBox add-on to view an enlarged version of the image in a lightbox, or overlay window. You can also zoom to change the size the lightbox image. If a single documentation page contains multiple images, you can navigate between images in the lightbox.

Prerequisites

  • The LightBox add-on is installed and enabled in your TechDocs plugin.

Procedure

  1. In your TechDocs documentation, click on the image that you want to view in a lightbox.
  2. In the lightbox, you can do any of the following actions:

    • Click the image or scroll to zoom in or zoom out.
    • Click the arrow to navigate between images.

3.4. Creating a TechDocs add-on

If your organization has documentation needs that are not met by the functions of existing TechDocs add-ons, developers can create a new add-on for your TechDocs plugin.

A TechDocs add-on is a React component that is imported from a front-end plugin. If you do not have an existing plugin that you can use to export your TechDocs add-on, you can create a new plugin by using backstage-cli to generate a default front-end plugin structure that you can customize.

The folder structure of a new plugin that can be used to import TechDocs add-ons into the TechDocs plugin looks similar to the following example:

<new_plugin_for_techdocs_add-on>/
   dev/
       index.ts
   src/
       components/
         <new_techdocs_add-on_component>/
              <new_techdocs_add-on_component>.test.tsx
              <new_techdocs_add-on_component>.tsx
               index.ts
         <new_techdocs_add-on_fetch-component>/
              <new_techdocs_add-on_fetch-component>.test.tsx
              <new_techdocs_add-on_fetch-component>.tsx
               index.ts
       index.ts
       plugin.test.ts
       plugin.ts
       routes.ts
       setupTests.ts
   .eslintrc.js
   package.json
   README.md

Prerequisites

  • The yarn package manager is installed.
  • Docker v3.2.0 or later or Podman v3.2.0 or later is installed and running.

Procedure

  1. In the terminal, navigate to the root folder of the repository where you want to create your new plugin.
  2. To create a new front-end plugin, run the following command:

    yarn new

    Example output

    ? What do you want to create? plugin - A new frontend plugin
    ? Enter the ID of the plugin [required]

  3. In the terminal prompt, type a name for the new plugin. For example:

    ? Enter the ID of the plugin [required] <new_plugin_for_techdocs_add-on>

    Example output

    Successfully created plugin

    Result

    In the plugins directory, a sub-directory with the same name that you gave to your plugin is automatically generated. The directory contains all of the files that you need to configure to create your new plugin.

  4. In the terminal, navigate to your new plugin directory. For example:

    cd plugins/<new_techdocs_add-on_directory>
  5. Add the`@backstage/plugin-techdocs-react` package to get frontend utilities for TechDocs add-ons. For example:

    yarn add @backstage/plugin-techdocs-react
  6. In the directory containing the components of your custom TechDocs add-on, delete any default files or file components that are not required for your add-on, such as the routes.ts file or components of the index.tsx and plugins.ts files.
  7. In the plugins.ts file, add the following code:

    import { createPlugin } from '@backstage/core-plugin-api';
    import { createTechDocsAddonExtension } from '@backstage/plugin-techdocs-react';
    
    export const <new_plugin_for_techdocs_add-on> = createPlugin({
      id: '<new_techdocs_add-on>',
     });
    
     /*
     *
     * @public
     */
    export const <new_techdocs_add-on> = <new_plugin_for_techdocs_add-on>.provide(
     createTechDocsAddonExtension<_<new_techdocs_addon_props>_>({
        name: '<new_techdocs_add-on>',
        location: TechDocsAddonLocations.Content,
        component: <new_techdocs_add-on_component>,
      }),
    );

    where

    <new_plugin_for_techdocs_add-on>
    Specifies the new plugin that you use to import the TechDocs add-on to your Red Hat Developer Hub instance.
    <new_techdocs_add-on>
    Specifies the custom TechDocs add-on that you want to create.
    <new_techdocs_addon_props> (Optional)
    Specifies the props for your new TechDocs add-on, as specified in your <new_techdocs_add-on>.tsx file, if applicable.
    <new_techdocs_add-on_component>
    Specifies the React component for the custom TechDocs add-on that you want to create. You will create this component in a .tsx file in a later step.
  8. In the index.ts file, export the custom TechDocs add-on that you want to create by adding the following code:

    export { <new_plugin_for_techdocs_add-on>, <new_techdocs_add-on> } from './plugin';
  9. Create a new <new_techdocs_add-on>.tsx file and add the code for your new TechDocs add-on component.
  10. Create a new index.tsx file and use it to export your new TechDocs add-on component by adding the following code:

    export { <new_techdocs_add-on>, type <new_techdocs_addon_props>} from './<new_techdocs_add-on_directory>'

    where

    <new_techdocs_addon_props> (Optional)
    Specifies the props for your new TechDocs add-on, as specified in your <new_techdocs_add-on>.tsx file, if applicable.
  11. In the plugins.ts file, import your new TechDocs add-on component.
  12. Install and configure your new TechDocs add-on by following the steps in Installing and configuring a TechDocs add-on

Verification

  1. Restart the RHDH application and verify that the plugin is successfully activated and configured.
  2. Verify the application logs for confirmation and ensure the plugin is functioning as expected.

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.