As a developer, you can use Red Hat Developer Hub to experience a streamlined development environment. Red Hat Developer Hub is driven by a centralized software catalog, providing efficiency to your microservices and infrastructure. It enables your product team to deliver quality code without any compromises.

Red Hat Developer Hub support

If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal. You can use the Red Hat Customer Portal for the following purposes:

  • To search or browse through the Red Hat Knowledgebase of technical support articles about Red Hat products.

  • To create a support case for Red Hat Global Support Services (GSS). For support case creation, select Red Hat Developer Hub as the product and select the appropriate product version.

Chapter 1. Overview of Red Hat Developer Hub

Red Hat Developer Hub (Developer Hub) serves as an open developer platform designed for building developer portals and is based on the backstage project. Using Developer Hub, the engineering teams can access a unified platform that streamlines the development process and provides a variety of tools and resources to build high-quality software efficiently.

The goal of Developer Hub is to address the difficulties associated with creating and sustaining developer portals using:

  • A centralized dashboard to view all available developer tools and resources to increase productivity

  • Self-service capabilities, along with guardrails, for cloud-native application development that complies with enterprise-class best practices

  • Proper security and governance for all developers across the enterprise

The Red Hat Developer Hub simplifies decision-making by providing a developer experience that presents a selection of internally approved tools, programming languages, and various developer resources within a self-managed portal. This approach contributes to the acceleration of application development and the maintenance of code quality, all while fostering innovation.

Chapter 2. Sizing requirements for Red Hat Developer Hub

Scalability of Red Hat Developer Hub requires significant resource allocation. The following table lists the sizing requirements for installing and running Red Hat Developer Hub, including both the Developer Hub application and Developer Hub database components.

Table 1. Recommended sizing for running Red Hat Developer Hub
Components Red Hat Developer Hub application Red Hat Developer Hub database

Central Processing Unit (CPU)

4 vCPU

2 vCPU

Memory

16 GB

8 GB

Storage size

2 GB

20 GB

Replicas

2 or more

3 or more

Chapter 3. Supported configurations for Red Hat Developer Hub

This section describes the configurations that are required to access the Red Hat Developer Hub, including:

  • Custom applications configuration

  • Source control configuration for Developer Hub Catalog

3.1. Adding a custom application configuration file to Red Hat OpenShift Container Platform

To access the Red Hat Developer Hub, you must add a custom application configuration file to Red Hat OpenShift Container Platform. In OpenShift Container Platform, you can use the following content as a base template to create a ConfigMap named app-config-rhdh:

kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
data:
  app-config-rhdh.yaml: |
    app:
      title: {product}

You can add the custom application configuration file to OpenShift Container Platform in one of the following ways:

  • The Red Hat Developer Hub Operator

  • The Red Hat Developer Hub Helm chart.

3.1.1. Adding a custom application configuration file to OpenShift Container Platform using the Helm chart

You can use the Red Hat Developer Hub Helm chart to add a custom application configuration file to your OpenShift Container Platform instance.

Prerequisites

  • You have created an Red Hat OpenShift Container Platform account.

Procedure

  1. From the OpenShift Container Platform web console, select the ConfigMaps tab.

  2. Click Create ConfigMap.

  3. From Create ConfigMap page, select the YAML view option in Configure via and make changes to the file, if needed.

  4. Click Create.

  5. Go to the Helm tab to see the list of Helm releases.

  6. Click the overflow menu on the Helm release that you want to use and select Upgrade.

  7. Use either the Form view or YAML view to edit the Helm configuration.

    • Using Form view

      1. Expand Root Schema → Backstage chart schema → Backstage parameters → Extra app configuration files to inline into command arguments.

      2. Click the Add Extra app configuration files to inline into command arguments link.

      3. Enter the value in the following fields:

        • configMapRef: app-config-rhdh

        • filename: app-config-rhdh.yaml

      4. Click Upgrade.

    • Using YAML view

      1. Set the value of the upstream.backstage.extraAppConfig.configMapRef and upstream.backstage.extraAppConfig.filename parameters as follows:

        # ... other Red Hat Developer Hub Helm Chart configurations
upstream:
  backstage:
    extraAppConfig:
      - configMapRef: app-config-rhdh
        filename: app-config-rhdh.yaml
# ... other Red Hat Developer Hub Helm Chart configurations

      2. Click Upgrade.

3.1.2. Adding a custom application configuration file to OpenShift Container Platform using the Operator

A custom application configuration file is a ConfigMap object that you can use to change the configuration of your Red Hat Developer Hub instance. If you are deploying your Developer Hub instance on Red Hat OpenShift Container Platform, you can use the Red Hat Developer Hub Operator to add a custom application configuration file to your OpenShift Container Platform instance by creating the ConfigMap object and referencing it in the Developer Hub custom resource (CR).

The custom application configuration file contains a sensitive environment variable, named BACKEND_SECRET. This variable contains a mandatory backend authentication key that Developer Hub uses to reference an environment variable defined in an OpenShift Container Platform secret. You must create a secret, named 'secrets-rhdh', and reference it in the Developer Hub CR.

Note

You are responsible for protecting your Red Hat Developer Hub installation from external and unauthorized access. Manage the backend authentication key like any other secret. Meet strong password requirements, do not expose it in any configuration files, and only inject it into configuration files as an environment variable.
Prerequisites

  • You have an active Red Hat OpenShift Container Platform account.

  • Your administrator has installed the Red Hat Developer Hub Operator in OpenShift Container Platform. For more information, see Installing the Red Hat Developer Hub Operator.

  • You have created the Red Hat Developer Hub CR in OpenShift Container Platform.

Procedure

  1. From the Developer perspective in the OpenShift Container Platform web console, select the Topology view, and click the Open URL icon on the Developer Hub pod to identify your Developer Hub external URL: <RHDH_URL>.

  2. From the Developer perspective in the OpenShift Container Platform web console, select the ConfigMaps view.

  3. Click Create ConfigMap.

  4. Select the YAML view option in Configure via and use the following example as a base template to create a ConfigMap object, such as app-config-rhdh.yaml:

    kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
data:
  "app-config-rhdh.yaml": |
    app:
      title: Red Hat Developer Hub
      baseUrl: <RHDH_URL> # (1)
    backend:
      auth:
        keys:
          - secret: "${BACKEND_SECRET}" # (2)
      baseUrl: <RHDH_URL> # (3)
      cors:
        origin: <RHDH_URL> # (4)

    1. Set the external URL of your Red Hat Developer Hub instance.

    2. Use an environment variable exposing an OpenShift Container Platform secret to define the mandatory Developer Hub backend authentication key.

    3. Set the external URL of your Red Hat Developer Hub instance.

    4. Set the external URL of your Red Hat Developer Hub instance.

  5. Click Create.

  6. Select the Secrets view.

  7. Click Create Key/value Secret.

  8. Create a secret named secrets-rhdh.

  9. Add a key named BACKEND_SECRET and a base64 encoded string as a value. Use a unique value for each Red Hat Developer Hub instance. For example, you can use the following command to generate a key from your terminal:

    node -p 'require("crypto").randomBytes(24).toString("base64")'

  10. Click Create.

  11. Select the Topology view.

  12. Click 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.

    operator install 2

  13. In the CR, enter the name of the custom application configuration config map as the value for the spec.application.appConfig.configMaps field, and enter the name of your secret as the value for the spec.application.extraEnvs.secrets field. For example:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: example
spec:
  application:
    appConfig:
      mountPath: /opt/app-root/src
      configMaps:
         - name: app-config-rhdh
    extraEnvs:
      secrets:
         - name: secrets-rhdh
    extraFiles:
      mountPath: /opt/app-root/src
    replicas: 1
    route:
      enabled: true
  database:
    enableLocalDb: true

  14. Click Save.

  15. Navigate back to the Topology view and wait for the Red Hat Developer Hub pod to start.

  16. Click the Open URL icon to use the Red Hat Developer Hub platform with the configuration changes.

Additional resources

3.2. Adding source control for Catalog in Red Hat Developer Hub

To populate the Catalog in Red Hat Developer Hub, you need to add software templates, and to add the templates, you must enable a supported source control such as GitHub.

Prerequisites

  • You have a GitHub account.

  • You have an account on the Red Hat OpenShift cluster.

  • You have installed the Developer Hub, otherwise the GitHub login fails.

3.2.1. Configuring GitHub authentication

The configuration of GitHub authentication is required to enable the GitHub OAuth login in Developer Hub.

Procedure

  1. In the Red Hat OpenShift cluster, navigate to the main page of the GitHub organization where you want to create the OAuth application.

  2. Click Settings → Developer Settings → OAuth Apps → Register an application

  3. Enter the application name as Developer Hub.

  4. Add the following URL as the Homepage URL:

    https://developer-hub-<NAMESPACE_NAME>.<OPENSHIFT_ROUTE_HOST>/

  5. Add the following URL as Authorization callback URL:

    https://developer-hub-<NAMESPACE_NAME>.<OPENSHIFT_ROUTE_HOST>/api/auth/github/handler/frame

  6. Clear the Enable Device Flow checkbox.

  7. Click Register application to create your OAuth application.

  8. After creating the application, click Generate a new client secret and copy the generated client secret.

  9. In OpenShift, click ConfigMaps.

  10. Generate a key/value secret named 'github-secrets' using the provided environment variables as keys, and input the values you generated for your GitHub OAuth application:

    1. In Red Hat OpenShift, go to the Secrets tab and click Create.

    2. Select Key/value secret.

    3. Enter Secret name as github-secrets.

    4. Add environment variables as Key and Value and click Create.

      Table 2. Environment variables
      Key Value

      GITHUB_OAUTH_CLIENT_ID

      Client ID from OAuth application

      GITHUB_OAUTH_CLIENT_SECRET

      Client Secret from OAuth application

  11. Modify your app-config-rhdh ConfigMap to include the GitHub authentication configuration as follows:

    kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
data:
  app-config-rhdh.yaml: |
    app:
      title: Red Hat Developer Hub
    auth:
      # see https://backstage.io/docs/auth/ to learn about auth providers
      environment: development
      providers:
        github:
          development:
            clientId: ${GITHUB_OAUTH_CLIENT_ID}
            clientSecret: ${GITHUB_OAUTH_CLIENT_SECRET}

  12. Click Save.

  13. Navigate to the Helm tab and select Upgrade.

  14. Use one of the following views to edit the Helm configuration:

    • Using Form view

      1. Expand Root Schema → Backstage Chart Schema → Backstage Parameters → Backstage container environment variables from existing Secrets.

      2. Click the Add Backstage container environment variables from existing Secrets link.

      3. Enter github-secrets as the value.

      4. Click Upgrade.

    • Using YAML view

      1. Set the value of the upstream.backstage.extraEnvVarsSecrets parameter to github-secrets as shown in the following example:

        # other Red Hat Developer Hub Helm Chart configurations
upstream:
  backstage:
    # other Red Hat Developer Hub Helm Chart configurations
    extraEnvVarsSecrets:
      - github-secrets
    # other Red Hat Developer Hub Helm Chart configurations

      2. Click Upgrade.

3.2.2. Configuring GitHub integration

The configuration of GitHub is required to enable the GitHub plugins in Developer Hub.

Procedure

  1. In the Red Hat OpenShift cluster, navigate to the main page of the GitHub organization where you want to create the OAuth application.

  2. Click Settings → Developer Settings → GitHub Apps → New GitHub App.

  3. Enter the application name as Developer Hub.

  4. Add the following URL as the Homepage URL:

    https://developer-hub-<NAMESPACE_NAME>.<OPENSHIFT_ROUTE_HOST>/

  5. Add the following URL as Authorization callback URL:

    https://developer-hub-<NAMESPACE_NAME>.<OPENSHIFT_ROUTE_HOST>/api/auth/github/handler/frame

  6. Deselect Webhook URL → Active.

  7. Under the Where can this GitHub App be installed? section, ensure that Only on this account is selected.

  8. Click Register application.

  9. After creating the application, click Generate a new client secret and copy the generated client secret.

  10. Click Generate a private key at the bottom of the page and download the generated file.

  11. In OpenShift, click ConfigMaps.

  12. Generate a key/value secret named 'github-secrets' using the provided environment variables as keys, and input the values you generated for your GitHub OAuth application:

    1. In Red Hat OpenShift, go to the Secrets tab and click Create.

    2. Select Key/value secret.

    3. Enter Secret name as github-secrets.

    4. Add environment variables as Key and Value and click Create.

    Table 3. Environment variables
    Key Value

    GITHUB_APP_APP_ID

    App ID from GitHub application

    GITHUB_APP_CLIENT_ID

    Client ID from GitHub application

    GITHUB_APP_CLIENT_SECRET

    Client Secret from GitHub application

    GITHUB_APP_WEBHOOK_URL

    Enter "none"

    GITHUB_APP_WEBHOOK_SECRET

    Enter "none"

    GITHUB_APP_PRIVATE_KEY

    Upload the private key that was downloaded

  13. Modify your app-config-rhdh ConfigMap to include the GitHub integration configuration as follows:

    kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
data:
  app-config-rhdh.yaml: |
    app:
      title: Red Hat Developer Hub
    integrations:
      github:
        - host: github.com
          apps:
            - appId: ${GITHUB_APP_APP_ID}
              clientId: ${GITHUB_APP_CLIENT_ID}
              clientSecret: ${GITHUB_APP_CLIENT_SECRET}
              webhookUrl: ${GITHUB_APP_WEBHOOK_URL}
              webhookSecret: ${GITHUB_APP_WEBHOOK_SECRET}
              privateKey: |
                ${GITHUB_APP_PRIVATE_KEY}

  14. Click Toplogy → developer hub → Actions (drop-down) → Restart rollout.

3.2.3. Enabling GitHub discovery in Red Hat Developer Hub

You can enable GitHub discoverability for your components in Developer Hub, such as any repositories that contain catalog-info.yaml file.

Prerequisites
Procedure

  1. In the Developer perspective of the OpenShift Container Platform web console, go to the Helm tab.

  2. Click the overflow menu on a Helm release and select Upgrade.

  3. Use one of the following views to edit the Helm configuration:

    • Using Form view

      1. Expand Root Schema → global → Dynamic plugins configuration → List of dynamic plugins that should be installed in the backstage application.

      2. Click the Add List of dynamic plugins that should be installed in the backstage application link.

      3. In the Package specification of the dynamic plugin to install. It should be usable by the npm pack command. field, add the following value:

        ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic

        enable gh discovery

      4. Click Upgrade.

    • Using YAML view

      1. Set the value of the global.dynamic.plugins.package parameter to ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic as shown in the following example:

        global:
  dynamic:
    # other Red Hat Developer Hub Helm Chart configurations
    plugins:
      - disabled: false
        package: >-
          ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic
    # other Red Hat Developer Hub Helm Chart configurations

      2. Click Upgrade.

  4. Add the following code in the ConfigMap:

    kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
data:
  app-config-rhdh.yaml: |
    ...
      catalog:
        providers:
          github:
            providerId:
              organization: '${GITHUB_ORG}'
              schedule:
                frequency:
                  minutes: 30
                initialDelay:
                  seconds: 15
                timeout:
                  minutes: 3
    ...

    In the previous code, replace ${GITHUB_ORG} with the GitHub organization from where you want to discover the components. Also, if there is a single provider, then following code can be added in the ConfigMap:

    kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
data:
  app-config-rhdh.yaml: |
    ...
    catalog:
      providers:
        github:
          organization: ${GITHUB_ORG}
          schedule:
            frequency: { minutes: 1 }
            timeout: { minutes: 1 }
            initialDelay: { seconds: 100 }
    ...

    The providerId in the previous code is required to identify the provider when there is a list of them.

  5. Click Save.

3.2.4. Enabling GitHub organization member discovery in Red Hat Developer Hub

You can also enable GitHub discoverability for the members of your GitHub organization.

Prerequisites
Procedure

  1. In the Developer perspective of the OpenShift Container Platform web console, go to the Helm tab.

  2. Click the overflow menu on a Helm release and select Upgrade.

  3. Use one of the following views to edit the Helm configuration:

    • Using Form view

      1. Expand Root Schema → global → Dynamic plugins configuration → List of dynamic plugins that should be installed in the backstage application.

      2. Click the Add List of dynamic plugins that should be installed in the backstage application link.

      3. In the Package specification of the dynamic plugin to install. It should be usable by the npm pack command. field, add the following value:

        ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic

        enable gh member discovery

      4. Click Upgrade.

    • Using YAML view

      1. Set the value of the global.dynamic.plugins.package parameter to ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic as shown in the following example:

        global:
  dynamic:
    # other Red Hat Developer Hub Helm Chart configurations
    plugins:
      - disabled: false
        package: >-
          ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic
    # other Red Hat Developer Hub Helm Chart configurations

      2. Click Upgrade.

  4. Add the following code in the ConfigMap:

    kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
data:
  app-config-rhdh.yaml: |
    ...
    catalog:
      providers:
        githubOrg:
          id: production
          githubUrl: "${GITHUB_URL}"
          orgs: [ "${GITHUB_ORG}" ]
    ...

    where:

    ${GITHUB_URL}

    Denotes a variable that you must replace with the GitHub URL.

    ${GITHUB_ORG}

    Denotes a variable that you must replace with the GitHub organization you want to ingest users from.

  5. Click Save.

Chapter 4. Customizing the Home page in Red Hat Developer Hub

To access the Home page in Red Hat Developer Hub, the base URL must include the /developer-hub proxy. You can configure the Home page by passing the data into the app-config.yaml file as a proxy. You can provide data to the Home page from the following sources:

  • JSON files hosted on GitHub or GitLab.

  • A dedicated service that provides the Home page data in JSON format using an API.

4.1. Using hosted JSON files to provide data to the Learning Paths

Prerequisites

You have installed Red Hat Developer Hub by using either the Operator or Helm chart.

Procedure

To access the data from the JSON files, complete the following step:

  • Add the following code to the app-config.yaml file:

    proxy:
  endpoints:
    # Other Proxies
    # customize developer hub instance
    '/developer-hub':
      target: <DOMAIN_URL> # i.e https://raw.githubusercontent.com/
      pathRewrite:
        '^/api/proxy/developer-hub': <path to json file> # i.e /janus-idp/backstage-showcase/main/packages/app/public/homepage/data.json
      changeOrigin: true
      secure: true
      # Change to "false" in case of using self hosted cluster with a self-signed certificate
      headers:
	<HEADER_KEY>: <HEADER_VALUE> # optional and can be passed as needed i.e Authorization can be passed for private GitHub repo and PRIVATE-TOKEN can be passed for private GitLab repo

4.2. Using a dedicated service to provide data to the Learning Paths

When using a dedicated service, you can do the following:

  • Use the same service to provide the data to all configurable Developer Hub pages or use a different service for each page.

  • Use the red-hat-developer-hub-customization-provider as an example service, which provides data for both the Home and Tech Radar pages. The red-hat-developer-hub-customization-provider service provides the same data as default Developer Hub data. You can fork the red-hat-developer-hub-customization-provider service repository from GitHub and modify it with your own data, if required.

  • Deploy the red-hat-developer-hub-customization-provider service and the Developer Hub Helm chart on the same cluster.

Prerequisites

  • You have installed the Red Hat Developer Hub using Helm Chart.

Procedure

To use a separate service to provide the Home page data, complete the following steps:

  1. From the Developer perspective in the Red Hat OpenShift Container Platform web console, click +Add > Import from Git.

  2. Enter the URL of your Git repository into the Git Repo URL field.

    To use the red-hat-developer-hub-customization-provider service, add the URL for the red-hat-developer-hub-customization-provider repository or your fork of the repository containing your customizations.

  3. On the General tab, enter red-hat-developer-hub-customization-provider in the Name field and click Create.

  4. On the Advanced Options tab, copy the value from the Target Port.

    Note

    The Target Port automatically generates a Kubernetes or OpenShift Container Platform service to communicate with.

  5. Add the following code to the app-config-rhdh.yaml file:

    proxy:
  endpoints:
    # Other Proxies
    # customize developer hub instance
    '/developer-hub':
      target: ${HOMEPAGE_DATA_URL}
      changeOrigin: true
      # Change to "false" in case of using self-hosted cluster with a self-signed certificate
      secure: true

    where HOMEPAGE_DATA_URL is defined as http://<SERVICE_NAME>:8080, for example, http://rhdh-customization-provider:8080.

    Note

    The red-hat-developer-hub-customization-provider service contains the 8080 port by default. If you are using a custom port, you can specify it with the 'PORT' environmental variable in the app-config-rhdh.yaml file.

  6. Replace the HOMEPAGE_DATA_URL by adding the URL to rhdh-secrets or by directly replacing it in your custom ConfigMap.

  7. Delete the Developer Hub pod to ensure that the new configurations are loaded correctly.

Verification

  • To view the service, navigate to the Administrator perspective in the OpenShift Container Platform web console and click Networking > Service.

    Note

    You can also view the Service Resources in the Topology view.

  • Ensure that the provided API URL for the Home page returns the data in JSON format as shown in the following example:

    [
  {
    "title": "Dropdown 1",
    "isExpanded": false,
    "links": [
      {
        "iconUrl": "https://imagehost.com/image.png",
        "label": "Dropdown 1 Item 1",
        "url": "https://example.com/"
      },
      {
        "iconUrl": "https://imagehost2.org/icon.png",
        "label": "Dropdown 1 Item 2",
        "url": ""
      }
    ]
  },
  {
    "title": "Dropdown 2",
    "isExpanded": true,
    "links": [
      {
        "iconUrl": "http://imagehost3.edu/img.jpg",
        "label": "Dropdown 2 Item 1",
        "url": "http://example.com"
      }
    ]
  }
]
    Note

    If the request call fails or is not configured, the Developer Hub instance falls back to the default local data.

  • If the images or icons do not load, then allowlist them by adding your image or icon host URLs to the content security policy’s (csp) img-src in your custom ConfigMap as follows:

kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
data:
  app-config-rhdh.yaml: |
    app:
      title: Red Hat Developer Hub
    backend:
      csp:
        connect-src:
          - "'self'"
          - 'http:'
          - 'https:'
        img-src:
          - "'self'"
          - 'data:'
          - <image host url 1>
          - <image host url 2>
          - <image host url 3>
    # Other Configurations

Chapter 5. Customizing the Tech Radar page in Red Hat Developer Hub

In Red Hat Developer Hub, the Tech Radar page is provided by the tech-radar dynamic plugin, which is disabled by default. For information about enabling dynamic plugins in Red Hat Developer Hub see Configuring plugins in Red Hat Developer Hub.

In Red Hat Developer Hub, you can configure Learning Paths by passing the data into the app-config.yaml file as a proxy. The base Tech Radar URL must include the /developer-hub/tech-radar proxy.

Note

Due to the use of overlapping pathRewrites for both the tech-radar and homepage quick access proxies, you must create the tech-radar configuration (^api/proxy/developer-hub/tech-radar) before you create the homepage configuration (^/api/proxy/developer-hub).

For more information about customizing the Home page in Red Hat Developer Hub, see Customizing the Home page in Red Hat Developer Hub.

You can provide data to the Tech Radar page from the following sources:

  • JSON files hosted on GitHub or GitLab.

  • A dedicated service that provides the Tech Radar data in JSON format using an API.

5.1. Using hosted JSON files to provide data to the Tech Radar page

Prerequisites

You have installed Red Hat Developer Hub by using either the Operator or Helm chart.

Procedure

To access the data from the JSON files, complete the following step:

  • Add the following code to the app-config.yaml file:

    proxy:
  endpoints:
    # Other Proxies
    # customize developer hub instance
    '/developer-hub':
      target: <DOMAIN_URL> # i.e https://raw.githubusercontent.com/
      pathRewrite:
        '^/api/proxy/developer-hub/tech-radar': <path to json file> # i.e /janus-idp/backstage-showcase/main/packages/app/public/tech-radar/data-default.json
	 '^/api/proxy/developer-hub': <path to json file> # i.e /janus-idp/backstage-showcase/main/packages/app/public/homepage/data.json
      changeOrigin: true
      secure: true

      # Change to "false" in case of using self hosted cluster with a self-signed certificate
      headers:
	<HEADER_KEY>: <HEADER_VALUE> # optional and can be passed as needed i.e Authorization can be passed for private GitHub repo and PRIVATE-TOKEN can be passed for private GitLab repo

5.2. Using a dedicated service to provide data to the Tech Radar page

When using a dedicated service, you can do the following:

  • Use the same service to provide the data to all configurable Developer Hub pages or use a different service for each page.

  • Use the red-hat-developer-hub-customization-provider as an example service, which provides data for both the Home and Tech Radar pages. The red-hat-developer-hub-customization-provider service provides the same data as default Developer Hub data. You can fork the red-hat-developer-hub-customization-provider service repository from GitHub and modify it with your own data, if required.

  • Deploy the red-hat-developer-hub-customization-provider service and the Developer Hub Helm chart on the same cluster.

Prerequisites

  • You have installed the Red Hat Developer Hub using Helm Chart.

Procedure

To use a separate service to provide the Tech Radar data, complete the following steps:

  1. Add the following code to the app-config-rhdh.yaml file:

    proxy:
  endpoints:
    # Other Proxies
    '/developer-hub/tech-radar':
      target: ${TECHRADAR_DATA_URL}
      changeOrigin: true
      # Change to "false" in case of using self hosted cluster with a self-signed certificate
      secure: true

    where the TECHRADAR_DATA_URL is defined as http://<SERVICE_NAME>/tech-radar, for example, http://rhdh-customization-provider/tech-radar.

    Note

    You can define the TECHRADAR_DATA_URL by adding it to rhdh-secrets or by directly replacing it with its value in your custom ConfigMap.

  2. Delete the Developer Hub pod to ensure that the new configurations are loaded correctly.

Chapter 6. Customizing the Learning Paths in Red Hat Developer Hub

In Red Hat Developer Hub, you can configure Learning Paths by passing the data into the app-config.yaml file as a proxy. The base Tech Radar URL must include the /developer-hub/learning-paths proxy.

Note

Due to the use of overlapping pathRewrites for both the learning-path and homepage quick access proxies, you must create the learning-paths configuration (^api/proxy/developer-hub/learning-paths) before you create the homepage configuration (^/api/proxy/developer-hub).

For more information about customizing the Home page in Red Hat Developer Hub, see Customizing the Home page in Red Hat Developer Hub.

You can provide data to the Learning Path from the following sources:

  • JSON files hosted on GitHub or GitLab.

  • A dedicated service that provides the Learning Path data in JSON format using an API.

6.1. Using hosted JSON files to provide data to the Learning Paths

Prerequisites

You have installed Red Hat Developer Hub by using either the Operator or Helm chart.

Procedure

To access the data from the JSON files, complete the following step:

  • Add the following code to the app-config.yaml file:

    proxy:
  endpoints:
    '/developer-hub':
      target: https://raw.githubusercontent.com/
      pathRewrite:
        '^/api/proxy/developer-hub/learning-paths': '/janus-idp/backstage-showcase/main/packages/app/public/learning-paths/data.json'
        '^/api/proxy/developer-hub/tech-radar': '/janus-idp/backstage-showcase/main/packages/app/public/tech-radar/data-default.json'
        '^/api/proxy/developer-hub': '/janus-idp/backstage-showcase/main/packages/app/public/homepage/data.json'
      changeOrigin: true
      secure: true

6.2. Using a dedicated service to provide data to the Learning Paths

When using a dedicated service, you can do the following:

  • Use the same service to provide the data to all configurable Developer Hub pages or use a different service for each page.

  • Use the red-hat-developer-hub-customization-provider as an example service, which provides data for both the Home and Tech Radar pages. The red-hat-developer-hub-customization-provider service provides the same data as default Developer Hub data. You can fork the red-hat-developer-hub-customization-provider service repository from GitHub and modify it with your own data, if required.

  • Deploy the red-hat-developer-hub-customization-provider service and the Developer Hub Helm chart on the same cluster.

Prerequisites

  • You have installed the Red Hat Developer Hub using Helm chart.

Procedure

To use a dedicated service to provide the Learning Path data, complete the following steps:

  1. Add the following code to the app-config-rhdh.yaml file:

       proxy:
      endpoints:
        # Other Proxies
        '/developer-hub/learning-paths':
          target: ${LEARNING_PATH_DATA_URL}
          changeOrigin: true
          # Change to "false" in case of using self hosted cluster with a self-signed certificate
          secure: true

    where the LEARNING_PATH_DATA_URL is defined as http://<SERVICE_NAME>/learning-paths, for example, http://rhdh-customization-provider/learning-paths.

    Note

    You can define the LEARNING_PATH_DATA_URL by adding it to rhdh-secrets or by directly replacing it with its value in your custom ConfigMap.

  2. Delete the Developer Hub pod to ensure that the new configurations are loaded correctly.

Chapter 7. Customizing the appearance of your Red Hat Developer Hub instance

The following default theme configurations are available for Red Hat Developer Hub:

The Red Hat Developer Hub theme

Default theme configurations to make your developer portal look like a standard Red Hat Developer Hub instance. For more information, see Default Red Hat Developer Hub theme

The Backstage theme

Default theme configurations to make your developer portal look like a standard Backstage instance. For more information, see Default Backstage theme

You can change or disable particular parameters in a default theme or create a fully customized theme by modifying the app-config-rhdh.yaml file. From the the app-config-rhdh.yaml file, you can customize common theme components, including the following:

  • Company name and logo

  • Font color, size, and style of text in paragraphs, headings, headers, and buttons

  • Header color, gradient, and shape

  • Button color

  • Navigation indicator color

You can also customize some components from the Developer Hub GUI, such as the theme mode (Light Theme, Dark Theme, or Auto).

7.1. Customizing the theme mode for your Developer Hub instance

Note

In Developer Hub, theme configurations are used to change the look and feel of different UI components. So, you might notice changes in different UI components, such as buttons, tabs, sidebars, cards, and tables along with some changes in background color and font used on the RHDH pages.

You can choose one of the following theme modes for your Developer Hub instance:

  • Light theme

  • Dark theme

  • Auto

The default theme mode is Auto, which automatically sets the light or dark theme based on your system preferences.

Prerequisites

  • You are logged in to the Developer Hub web console.

Procedure

  1. From the Developer Hub web console, click Settings.

  2. From the Appearance panel, click LIGHT THEME, DARK THEME, or AUTO to change the theme mode.

    custom theme mode 1

7.2. Customizing the sidebar logo width for your Developer Hub instance

You can customize the width of the sidebar logo by setting a value for the fullLogoWidth field in the branding section of the app-config-rhdh.yaml file, as shown in the following example:

app:
  branding:
    fullLogoWidth: 110px
# ...

The default value for the logo width is 110px. The following units are supported: integer, px, em, rem, percentage.

7.3. Customizing the application title for your Developer Hub instance

You can customize the app title text by setting a value for the title field, as shown in the following example:

app:
  title: My custom developer hub
# ...

7.4. Customizing the theme mode color palettes for your Developer Hub instance

You can customize the color palettes of the light and dark theme modes in your Developer Hub instance by configuring the light.palette and dark.palette parameters in the branding.theme section of the app-config-rhdh.yaml file, as shown in the following example:

app:
  branding:
    theme:
      light:
        palette:
          primary:
            main: <light_primary_color> (1)
          navigation:
            indicator: <light_indicator_color> (2)
        pageTheme:
          default:
            backgroundColor: [<light_background_color_1>, <light_background_color_2>] (3)
      dark:
        palette:
          primary:
            main: <dark_primary_color> (4)
          navigation:
            indicator: <dark_indicator_color> (5)
        pageTheme:
          default:
            backgroundColor: [<dark_background_color_1>, <dark_background_color_2>] (6)
# ...

  1. The main primary color for the light color palette, for example, #ffffff or white

  2. The color of the navigation indicator for the light color palette, which is a vertical bar that indicates the selected tab in the navigation panel, for example, #FF0000 or red

  3. The background color for the default page theme for the light color palette, for example, #ffffff or white

  4. The main primary color for the dark color palette, for example, #000000 or black

  5. The color of the navigation indicator for the dark color palette, which is a vertical bar that indicates the selected tab in the navigation panel, for example, #FF0000 or red

  6. The background color for the default page theme for the dark color palette, for example, #000000 or black

Additional resources

7.5. Customizing the page theme header for your Developer Hub instance

You can customize the header color for the light and dark theme modes in your Developer Hub instance by modifying the branding.theme section of the app-config-rhdh.yaml file. You can also customize the page headers for additional Developer Hub pages, such as the Home, Catalog, and APIs pages.

app:
  branding:
    theme:
      light: (1)
        palette: {}
        pageTheme:
          default: (2)
            backgroundColor: "<default_light_background_color>" (3)
            fontColor: "<default_light_font_color>" (4)
            shape: none (5)
          apis: (6)
            backgroundColor: "<apis_light_background_color>"
            fontColor: "<apis_light_font_color>"
            shape: none
      dark:
        palette: {}
        pageTheme:
          default:
            backgroundColor: "<default_dark_background_color>"
            fontColor: "<default_dark_font_color>"
            shape: none
# ...

  1. The theme mode, for example, light or dark

  2. The yaml header for the default page theme configuration

  3. The color of the page header background, for example, #ffffff or white

  4. The color of the text in the page header, for example, #000000 or black

  5. The pattern on the page header, for example, wave, round, or none

  6. The yaml header for a specific page theme configuration, for example, apis, home

7.6. Customizing the font for your Developer Hub instance

You can configure the typography section of the app-config-rhdh.yaml file to change the default font family and size of the page text, as well as the font family and size of each heading level, as shown in the following example:

app:
  branding:
    theme:
      light:
        typography:
          fontFamily: "Times New Roman"
          htmlFontSize: 11 # smaller is bigger
          h1:
            fontFamily: "Times New Roman"
            fontSize: 40
          h2:
            fontFamily: "Times New Roman"
            fontSize: 30
          h3:
            fontFamily: "Times New Roman"
            fontSize: 30
          h4:
            fontFamily: "Times New Roman"
            fontSize: 30
          h5:
            fontFamily: "Times New Roman"
            fontSize: 30
          h6:
            fontFamily: "Times New Roman"
            fontSize: 30
      dark:
        typography:
          fontFamily: "Times New Roman"
          htmlFontSize: 11 # smaller is bigger
          h1:
            fontFamily: "Times New Roman"
            fontSize: 40
          h2:
            fontFamily: "Times New Roman"
            fontSize: 30
          h3:
            fontFamily: "Times New Roman"
            fontSize: 30
          h4:
            fontFamily: "Times New Roman"
            fontSize: 30
          h5:
            fontFamily: "Times New Roman"
            fontSize: 30
          h6:
            fontFamily: "Times New Roman"
            fontSize: 30
# ...

7.7. Default Red Hat Developer Hub theme

You can use the default Red Hat Developer Hub theme configurations to make your Developer Hub instance look like a standard Red Hat Developer Hub instance. You can also modify the app-config-rhdh.yaml file to customize or disable particular parameters.

7.7.1. Default Red Hat Developer Hub theme color palette

The app-config-rhdh.yaml file uses the following configurations for the default Red Hat Developer Hub color palette:

app:
  branding:
    theme:
      light:
        variant: "rhdh"
        mode: "light"
        palette:
          background:
            default: "#F8F8F8"
            paper: "#FFFFFF"
          banner:
            closeButtonColor: "#FFFFFF"
            error: "#E22134"
            info: "#2E77D0"
            link: "#000000"
            text: "#FFFFFF"
            warning: "#FF9800"
          border: "#E6E6E6"
          bursts:
            backgroundColor:
              default: "#7C3699"
            fontColor: "#FEFEFE"
            gradient:
              linear: "linear-gradient(-137deg, #4BB8A5 0%, #187656 100%)"
            slackChannelText: "#ddd"
          errorBackground: "#FFEBEE"
          errorText: "#CA001B"
          gold: "#FFD600"
          highlight: "#FFFBCC"
          infoBackground: "#ebf5ff"
          infoText: "#004e8a"
          link: "#0A6EBE"
          linkHover: "#2196F3"
          mode: "light"
          navigation:
            background: "#222427"
            indicator: "#0066CC"
            color: "#ffffff"
            selectedColor: "#ffffff"
            navItem:
              hoverBackground: "#3c3f42"
            submenu:
              background: "#222427"
          pinSidebarButton:
            background: "#BDBDBD"
            icon: "#181818"
          primary:
            main: "#0066CC"
          secondary:
            main: "#8476D1"
          status:
            aborted: "#757575"
            error: "#E22134"
            ok: "#1DB954"
            pending: "#FFED51"
            running: "#1F5493"
            warning: "#FF9800"
          tabbar:
            indicator: "#9BF0E1"
          textContrast: "#000000"
          textSubtle: "#6E6E6E"
          textVerySubtle: "#DDD"
          warningBackground: "#F59B23"
          warningText: "#000000"
          text:
            primary: "#151515"
            secondary: "#757575"
          rhdh:
            general:
              disabledBackground: "#D2D2D2"
              disabled: "#6A6E73"
              searchBarBorderColor: "#E4E4E4"
              formControlBackgroundColor: "#FFF"
              mainSectionBackgroundColor: "#FFF"
              headerBottomBorderColor: "#C7C7C7"
              cardBackgroundColor: "#FFF"
              sideBarBackgroundColor: "#212427"
              cardBorderColor: "#C7C7C7"
              tableTitleColor: "#181818"
              tableSubtitleColor: "#616161"
              tableColumnTitleColor: "#151515"
              tableRowHover: "#F5F5F5"
              tableBorderColor: "#E0E0E0"
              tableBackgroundColor: "#FFF"
              tabsBottomBorderColor: "#D2D2D2"
              contrastText: "#FFF"
            primary:
              main: "#0066CC"
              focusVisibleBorder: "#0066CC"
            secondary:
              main: "#8476D1"
              focusVisibleBorder: "#8476D1"
            cards:
              headerTextColor: "#151515"
              headerBackgroundColor: "#FFF"
              headerBackgroundImage: "none"

      dark:
        variant: "rhdh"
        mode: "dark"
        palette:
          background:
            default: "#333333"
            paper: "#424242"
          banner:
            closeButtonColor: "#FFFFFF"
            error: "#E22134"
            info: "#2E77D0"
            link: "#000000"
            text: "#FFFFFF"
            warning: "#FF9800"
          border: "#E6E6E6"
          bursts:
            backgroundColor:
              default: "#7C3699"
            fontColor: "#FEFEFE"
            gradient:
              linear: "linear-gradient(-137deg, #4BB8A5 0%, #187656 100%)"
            slackChannelText: "#ddd"
          errorBackground: "#FFEBEE"
          errorText: "#CA001B"
          gold: "#FFD600"
          highlight: "#FFFBCC"
          infoBackground: "#ebf5ff"
          infoText: "#004e8a"
          link: "#9CC9FF"
          linkHover: "#82BAFD"
          mode: "dark"
          navigation:
            background: "#0f1214"
            indicator: "#0066CC"
            color: "#ffffff"
            selectedColor: "#ffffff"
            navItem:
              hoverBackground: "#3c3f42"
            submenu:
              background: "#0f1214"
          pinSidebarButton:
            background: "#BDBDBD"
            icon: "#404040"
          primary:
            main: "#1FA7F8"
          secondary:
            main: "#B2A3FF"
          status:
            aborted: "#9E9E9E"
            error: "#F84C55"
            ok: "#71CF88"
            pending: "#FEF071"
            running: "#3488E3"
            warning: "#FFB84D"
          tabbar:
            indicator: "#9BF0E1"
          textContrast: "#FFFFFF"
          textSubtle: "#CCCCCC"
          textVerySubtle: "#727272"
          warningBackground: "#F59B23"
          warningText: "#000000"

          rhdh:
            general:
              disabledBackground: "#444548"
              disabled: "#AAABAC"
              searchBarBorderColor: "#57585a"
              formControlBackgroundColor: "#36373A"
              mainSectionBackgroundColor: "#0f1214"
              headerBottomBorderColor: "#A3A3A3"
              cardBackgroundColor: "#292929"
              sideBarBackgroundColor: "#1b1d21"
              cardBorderColor: "#A3A3A3"
              tableTitleColor: "#E0E0E0"
              tableSubtitleColor: "#E0E0E0"
              tableColumnTitleColor: "#E0E0E0"
              tableRowHover: "#0f1214"
              tableBorderColor: "#515151"
              tableBackgroundColor: "#1b1d21"
              tabsBottomBorderColor: "#444548"
              contrastText: "#FFF"
            primary:
              main: "#1FA7F8"
              focusVisibleBorder: "#ADD6FF"
            secondary:
              main: "#B2A3FF"
              focusVisibleBorder: "#D0C7FF"
            cards:
              headerTextColor: "#FFF"
              headerBackgroundColor: "#0f1214"
              headerBackgroundImage: "none"

Alternatively, you can use the following variant and mode values in the app-config-rhdh.yaml file to apply the previous default configuration:

app:
  branding:
    theme:
      light:
        variant: "rhdh"
        mode: "light"
      dark:
        variant: "rhdh"
        mode: "dark"

7.7.2. Default Red Hat Developer Hub page themes

The default Developer Hub header color is white in light mode and black in dark mode, as shown in the following app-config-rhdh.yaml file configuration:

app:
  branding:
    theme:
      light:
        palette: {}
        defaultPageTheme: default
        pageTheme:
          default:
            backgroundColor: "#ffffff"
      dark:
        palette: {}
        defaultPageTheme: default
        pageTheme:
          default:
            backgroundColor: "#0f1214"

7.8. Default Backstage theme

You can use the default Backstage theme configurations to make your Developer Hub instance look like a standard Backstage instance. You can also modify the app-config-rhdh.yaml file to customize or disable particular parameters.

7.8.1. Default Backstage theme color palette

The app-config-rhdh.yaml file uses the following configurations for the default Backstage color palette:

app:
  branding:
    theme:
      light:
        variant: "backstage"
        mode: "light"
        palette:
          background:
            default: "#F8F8F8"
            paper: "#FFFFFF"
          banner:
            closeButtonColor: "#FFFFFF"
            error: "#E22134"
            info: "#2E77D0"
            link: "#000000"
            text: "#FFFFFF"
            warning: "#FF9800"
          border: "#E6E6E6"
          bursts:
            backgroundColor:
              default: "#7C3699"
            fontColor: "#FEFEFE"
            gradient:
              linear: "linear-gradient(-137deg, #4BB8A5 0%, #187656 100%)"
            slackChannelText: "#ddd"
          errorBackground: "#FFEBEE"
          errorText: "#CA001B"
          gold: "#FFD600"
          highlight: "#FFFBCC"
          infoBackground: "#ebf5ff"
          infoText: "#004e8a"
          link: "#0A6EBE"
          linkHover: "#2196F3"
          navigation:
            background: "#171717"
            color: "#b5b5b5"
            indicator: "#9BF0E1"
            navItem:
              hoverBackground: "#404040"
            selectedColor: "#FFF"
            submenu:
              background: "#404040"
          pinSidebarButton:
            background: "#BDBDBD"
            icon: "#181818"
          primary:
            main: "#1F5493"
          status:
            aborted: "#757575"
            error: "#E22134"
            ok: "#1DB954"
            pending: "#FFED51"
            running: "#1F5493"
            warning: "#FF9800"
          tabbar:
            indicator: "#9BF0E1"
          textContrast: "#000000"
          textSubtle: "#6E6E6E"
          textVerySubtle: "#DDD"
          warningBackground: "#F59B23"
          warningText: "#000000"

      dark:
        variant: "backstage"
        mode: "dark"
        palette:
          background:
            default: "#333333"
            paper: "#424242"
          banner:
            closeButtonColor: "#FFFFFF"
            error: "#E22134"
            info: "#2E77D0"
            link: "#000000"
            text: "#FFFFFF"
            warning: "#FF9800"
          border: "#E6E6E6"
          bursts:
            backgroundColor:
              default: "#7C3699"
            fontColor: "#FEFEFE"
            gradient:
              linear: "linear-gradient(-137deg, #4BB8A5 0%, #187656 100%)"
            slackChannelText: "#ddd"
          errorBackground: "#FFEBEE"
          errorText: "#CA001B"
          gold: "#FFD600"
          highlight: "#FFFBCC"
          infoBackground: "#ebf5ff"
          infoText: "#004e8a"
          link: "#9CC9FF"
          linkHover: "#82BAFD"
          mode: "dark"
          navigation:
            background: "#424242"
            color: "#b5b5b5"
            indicator: "#9BF0E1"
            navItem:
              hoverBackground: "#404040"
            selectedColor: "#FFF"
            submenu:
              background: "#404040"
          pinSidebarButton:
            background: "#BDBDBD"
            icon: "#404040"
          primary:
            dark: "#82BAFD"
            main: "#9CC9FF"
          secondary:
            main: "#FF88B2"
          status:
            aborted: "#9E9E9E"
            error: "#F84C55"
            ok: "#71CF88"
            pending: "#FEF071"
            running: "#3488E3"
            warning: "#FFB84D"
          tabbar:
            indicator: "#9BF0E1"
          textContrast: "#FFFFFF"
          textSubtle: "#CCCCCC"
          textVerySubtle: "#727272"
          warningBackground: "#F59B23"
          warningText: "#000000"

Alternatively, you can use the following variant and mode values in the app-config-rhdh.yaml file to apply the previous default configuration:

app:
  branding:
    theme:
      light:
        variant: "backstage"
        mode: "light"
      dark:
        variant: "backstage"
        mode: "dark"

7.8.2. Default Backstage page themes

The default Backstage header color is white in light mode and black in dark mode, as shown in the following app-config-rhdh.yaml file configuration:

app:
  branding:
    theme:
      light:
        palette: {}
        defaultPageTheme: default
        pageTheme:
          default:
            backgroundColor: ['#005B4B'] # teal
            fontColor: '#ffffff'
            shape: wave
          documentation:
            backgroundColor: ['#C8077A', '#C2297D'] # pinkSea
            fontColor: '#ffffff'
            shape: wave2
          tool:
            backgroundColor: ['#8912CA', '#3E00EA'] # purpleSky
            fontColor: '#ffffff'
            shape: round
          service:
            backgroundColor: ['#006D8F', '#0049A1'] # marineBlue
            fontColor: '#ffffff'
            shape: wave
          website:
            backgroundColor: ['#0027AF', '#270094'] # veryBlue
            fontColor: '#ffffff'
            shape: wave
          library:
            backgroundColor: ['#98002B', '#8D1134'] # rubyRed
            fontColor: '#ffffff'
            shape: wave
          other:
            backgroundColor: ['#171717', '#383838'] # darkGrey
            fontColor: '#ffffff'
            shape: wave
          app:
            backgroundColor: ['#BE2200', '#A41D00'] # toastyOrange
            fontColor: '#ffffff'
            shape: shapes.wave
          apis:
            backgroundColor: ['#005B4B'] # teal
            fontColor: '#ffffff'
            shape: wave2
          card:
            backgroundColor: ['#4BB8A5', '#187656'] # greens
            fontColor: '#ffffff'
            shape: wave

      dark:
        palette: {}
        defaultPageTheme: default
        pageTheme:
          default:
            backgroundColor: ['#005B4B'] # teal
            fontColor: '#ffffff'
            shape: wave
          documentation:
            backgroundColor: ['#C8077A', '#C2297D'] # pinkSea
            fontColor: '#ffffff'
            shape: wave2
          tool:
            backgroundColor: ['#8912CA', '#3E00EA'] # purpleSky
            fontColor: '#ffffff'
            shape: round
          service:
            backgroundColor: ['#006D8F', '#0049A1'] # marineBlue
            fontColor: '#ffffff'
            shape: wave
          website:
            backgroundColor: ['#0027AF', '#270094'] # veryBlue
            fontColor: '#ffffff'
            shape: wave
          library:
            backgroundColor: ['#98002B', '#8D1134'] # rubyRed
            fontColor: '#ffffff'
            shape: wave
          other:
            backgroundColor: ['#171717', '#383838'] # darkGrey
            fontColor: '#ffffff'
            shape: wave
          app:
            backgroundColor: ['#BE2200', '#A41D00'] # toastyOrange
            fontColor: '#ffffff'
            shape: shapes.wave
          apis:
            backgroundColor: ['#005B4B'] # teal
            fontColor: '#ffffff'
            shape: wave2
          card:
            backgroundColor: ['#4BB8A5', '#187656'] # greens
            fontColor: '#ffffff'
            shape: wave

7.9. Custom component options for your Developer Hub instance

There are two component variants that you can use to customize various components of your Developer Hub theme:

  • Patternfly

  • MUI

In addition to assigning a component variant to each parameter in the light or dark theme mode configurations, you can toggle the rippleEffect on or off.

The following code shows the options that you can use in the app-config-rhdh.yaml file to configure the theme components for your Developer Hub instance:

app:
  branding:
    theme:
      light:
        options:
          rippleEffect: off / on
          paper: patternfly / mui
          buttons: patternfly / mui
          inputs: patternfly / mui
          accordions: patternfly / mui
          sidebars: patternfly / mui
          pages: patternfly / mui
          headers: patternfly / mui
          toolbars: patternfly / mui
          dialogs: patternfly / mui
          cards: patternfly / mui
          tables: patternfly / mui
          tabs: patternfly / mui
      dark:
        options:
          rippleEffect: off / on
          paper: patternfly / mui
          buttons: patternfly / mui
          inputs: patternfly / mui
          accordions: patternfly / mui
          sidebars: patternfly / mui
          pages: patternfly / mui
          headers: patternfly / mui
          toolbars: patternfly / mui
          dialogs: patternfly / mui
          cards: patternfly / mui
          tables: patternfly / mui
          tabs: patternfly / mui

Chapter 8. ServiceNow Custom actions in Red Hat Developer Hub

Important

These features are for Technology Preview only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information on Red Hat Technology Preview features, see Technology Preview Features Scope.

In Red Hat Developer Hub, you can access ServiceNow custom actions (custom actions) for fetching and registering resources in the catalog.

The custom actions in Developer Hub enable you to facilitate and automate the management of records. Using the custom actions, you can perform the following actions:

  • Create, update, or delete a record

  • Retrieve information about a single record or multiple records

8.1. Enabling ServiceNow custom actions plugin in Red Hat Developer Hub

In Red Hat Developer Hub, the ServiceNow custom actions are provided as a pre-loaded plugin, which is disabled by default. You can enable the custom actions plugin using the following procedure.

Prerequisites

  • Red Hat Developer Hub is installed and running.

  • You have created a project in the Developer Hub.

Procedure

  1. To activate the custom actions plugin, add a package with plugin name and update the disabled field in your Helm Chart as follows:

    global:
  dynamic:
    includes:
      - dynamic-plugins.default.yaml
    plugins:
      - package: ./dynamic-plugins/dist/janus-idp-backstage-scaffolder-backend-module-servicenow-dynamic
        disabled: false
    Note

    The default configuration for a plugin is extracted from the dynamic-plugins.default.yaml file, however, you can use a pluginConfig entry to override the default configuration.

  2. Set the following variables in the Helm Chart to access the custom actions:

    servicenow:
  # The base url of the ServiceNow instance.
  baseUrl: ${SERVICENOW_BASE_URL}
  # The username to use for authentication.
  username: ${SERVICENOW_USERNAME}
  # The password to use for authentication.
  password: ${SERVICENOW_PASSWORD}

8.2. Supported ServiceNow custom actions in Red Hat Developer Hub

The ServiceNow custom actions enable you to manage records in the Red Hat Developer Hub. The custom actions support the following HTTP methods for API requests:

  • GET: Retrieves specified information from a specified resource endpoint

  • POST: Creates or updates a resource

  • PUT: Modify a resource

  • PATCH: Updates a resource

  • DELETE: Deletes a resource

8.2.1. ServiceNow custom actions

[GET] servicenow:now:table:retrieveRecord

Retrieves information of a specified record from a table in the Developer Hub.

Table 4. Input parameters
Name Type Requirement Description

tableName

string

Required

Name of the table to retrieve the record from

sysId

string

Required

Unique identifier of the record to retrieve

sysparmDisplayValue

enum("true", "false", "all")

Optional

Returns field display values such as true, actual values as false, or both. The default value is false.

sysparmExcludeReferenceLink

boolean

Optional

Set as true to exclude Table API links for reference fields. The default value is false.

sysparmFields

string[]

Optional

Array of fields to return in the response

sysparmView

string

Optional

Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.

sysparmQueryNoDomain

boolean

Optional

Set as true to access data across domains if authorized. The default value is false.
Table 5. Output parameters
Name Type Description

result

Record<PropertyKey, unknown>

The response body of the request
[GET] servicenow:now:table:retrieveRecords

Retrieves information about multiple records from a table in the Developer Hub.

Table 6. Input parameters
Name Type Requirement Description

tableName

string

Required

Name of the table to retrieve the records from

sysparamQuery

string

Optional

Encoded query string used to filter the results

sysparmDisplayValue

enum("true", "false", "all")

Optional

Returns field display values such as true, actual values as false, or both. The default value is false.

sysparmExcludeReferenceLink

boolean

Optional

Set as true to exclude Table API links for reference fields. The default value is false.

sysparmSuppressPaginationHeader

boolean

Optional

Set as true to suppress pagination header. The default value is false.

sysparmFields

string[]

Optional

Array of fields to return in the response

sysparmLimit

int

Optional

Maximum number of results returned per page. The default value is 10,000.

sysparmView

string

Optional

Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.

sysparmQueryCategory

string

Optional

Name of the query category to use for queries

sysparmQueryNoDomain

boolean

Optional

Set as true to access data across domains if authorized. The default value is false.

sysparmNoCount

boolean

Optional

Does not execute a select count(*) on the table. The default value is false.
Table 7. Output parameters
Name Type Description

result

Record<PropertyKey, unknown>

The response body of the request
[POST] servicenow:now:table:createRecord

Creates a record in a table in the Developer Hub.

Table 8. Input parameters
Name Type Requirement Description

tableName

string

Required

Name of the table to save the record in

requestBody

Record<PropertyKey, unknown>

Optional

Field name and associated value for each parameter to define in the specified record

sysparmDisplayValue

enum("true", "false", "all")

Optional

Returns field display values such as true, actual values as false, or both. The default value is false.

sysparmExcludeReferenceLink

boolean

Optional

Set as true to exclude Table API links for reference fields. The default value is false.

sysparmFields

string[]

Optional

Array of fields to return in the response

sysparmInputDisplayValue

boolean

Optional

Set field values using their display value such as true or actual value as false. The default value is false.

sysparmSuppressAutoSysField

boolean

Optional

Set as true to suppress auto-generation of system fields. The default value is false.

sysparmView

string

Optional

Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.
Table 9. Output parameters
Name Type Description

result

Record<PropertyKey, unknown>

The response body of the request
[PUT] servicenow:now:table:modifyRecord

Modifies a record in a table in the Developer Hub.

Table 10. Input parameters
Name Type Requirement Description

tableName

string

Required

Name of the table to modify the record from

sysId

string

Required

Unique identifier of the record to modify

requestBody

Record<PropertyKey, unknown>

Optional

Field name and associated value for each parameter to define in the specified record

sysparmDisplayValue

enum("true", "false", "all")

Optional

Returns field display values such as true, actual values as false, or both. The default value is false.

sysparmExcludeReferenceLink

boolean

Optional

Set as true to exclude Table API links for reference fields. The default value is false.

sysparmFields

string[]

Optional

Array of fields to return in the response

sysparmInputDisplayValue

boolean

Optional

Set field values using their display value such as true or actual value as false. The default value is false.

sysparmSuppressAutoSysField

boolean

Optional

Set as true to suppress auto-generation of system fields. The default value is false.

sysparmView

string

Optional

Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.

sysparmQueryNoDomain

boolean

Optional

Set as true to access data across domains if authorized. The default value is false.
Table 11. Output parameters
Name Type Description

result

Record<PropertyKey, unknown>

The response body of the request
[PATCH] servicenow:now:table:updateRecord

Updates a record in a table in the Developer Hub.

Table 12. Input parameters
Name Type Requirement Description

tableName

string

Required

Name of the table to update the record in

sysId

string

Required

Unique identifier of the record to update

requestBody

Record<PropertyKey, unknown>

Optional

Field name and associated value for each parameter to define in the specified record

sysparmDisplayValue

enum("true", "false", "all")

Optional

Returns field display values such as true, actual values as false, or both. The default value is false.

sysparmExcludeReferenceLink

boolean

Optional

Set as true to exclude Table API links for reference fields. The default value is false.

sysparmFields

string[]

Optional

Array of fields to return in the response

sysparmInputDisplayValue

boolean

Optional

Set field values using their display value such as true or actual value as false. The default value is false.

sysparmSuppressAutoSysField

boolean

Optional

Set as true to suppress auto-generation of system fields. The default value is false.

sysparmView

string

Optional

Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.

sysparmQueryNoDomain

boolean

Optional

Set as true to access data across domains if authorized. The default value is false.
Table 13. Output parameters
Name Type Description

result

Record<PropertyKey, unknown>

The response body of the request
[DELETE] servicenow:now:table:deleteRecord

Deletes a record from a table in the Developer Hub.

Table 14. Input parameters
Name Type Requirement Description

tableName

string

Required

Name of the table to delete the record from

sysId

string

Required

Unique identifier of the record to delete

sysparmQueryNoDomain

boolean

Optional

Set as true to access data across domains if authorized. The default value is false.

Chapter 9. Audit logs in Red Hat Developer Hub

Audit logs are a chronological set of records documenting the user activities, system events, and data changes that affect your Red Hat Developer Hub users, administrators, or components. Administrators can view Developer Hub audit logs in the OpenShift Container Platform web console to monitor scaffolder events, changes to the RBAC system, and changes to the Catalog database. Audit logs include the following information:

  • Name of the audited event

  • Actor that triggered the audited event, for example, terminal, port, IP address, or hostname

  • Event metadata, for example, date, time

  • Event status, for example, success, failure

  • Severity levels, for example, info, debug, warn, error

You can use the information in the audit log to achieve the following goals:

Enhance security

Trace activities, including those initiated by automated systems and software templates, back to their source. Know when software templates are executed, as well as the details of application and component installations, updates, configuration changes, and removals.

Automate compliance

Use streamlined processes to view log data for specified points in time for auditing purposes or continuous compliance maintenance.

Debug issues

Use access records and activity details to fix issues with software templates or plugins.

Note

Audit logs are not forwarded to the internal log store by default because this does not provide secure storage. You are responsible for ensuring that the system to which you forward audit logs is compliant with your organizational and governmental regulations, and is properly secured.
Additional resources

9.1. Configuring audit logs for Developer Hub on OpenShift Container Platform

Use the OpenShift Container Platform web console to configure the following OpenShift Container Platform logging components to use audit logging for Developer Hub:

Logging deployment

Configure the logging environment, including both the CPU and memory limits for each logging component. For more information, see Red Hat OpenShift Container Platform - Configuring your Logging deployment.

Logging collector

Configure the spec.collection stanza in the ClusterLogging custom resource (CR) to use a supported modification to the log collector and collect logs from STDOUT. For more information, see Red Hat OpenShift Container Platform - Configuring the logging collector.

Log forwarding

Send logs to specific endpoints inside and outside your OpenShift Container Platform cluster by specifying a combination of outputs and pipelines in a ClusterLogForwarder CR. For more information, see Red Hat OpenShift Container Platform - Enabling JSON log forwarding and Red Hat OpenShift Container Platform - Configuring log forwarding.

9.2. Viewing audit logs in Developer Hub

Administrators can view, search, filter, and manage the log data from the Red Hat OpenShift Container Platform web console. You can filter audit logs from other log types by using the isAuditLog field.

Prerequisites

  • You are logged in as an administrator in the OpenShift Container Platform web console.

Procedure

  1. From the Developer perspective of the OpenShift Container Platform web console, click the Topology tab.

  2. From the Topology view, click the pod that you want to view audit log data for.

  3. From the pod panel, click the Resources tab.

  4. From the Pods section of the Resources tab, click View logs.

  5. From the Logs view, enter isAuditLog into the Search field to filter audit logs from other log types. You can use the arrows to browse the logs containing the isAuditLog field.

9.2.1. Audit log fields

Developer Hub audit logs can include the following fields:

eventName

The name of the audited event.

actor

An object containing information about the actor that triggered the audited event. Contains the following fields:

actorId

The name/id/entityRef of the associated user or service. Can be null if an unauthenticated user accesses the endpoints and the default authentication policy is disabled.

ip

The IP address of the actor (optional).

hostname

The hostname of the actor (optional).

client

The user agent of the actor (optional).

stage

The stage of the event at the time that the audit log was generated, for example, initiation or completion.

status

The status of the event, for example, succeeded or failed.

meta

An optional object containing event specific data, for example, taskId.

request

An optional field that contains information about the HTTP request sent to an endpoint. Contains the following fields:

method

The HTTP method of the request.

query

The query fields of the request.

params

The params fields of the request.

body

The request body. The secrets provided when creating a task are redacted and appear as *.

url

The endpoint URL of the request.

response

An optional field that contains information about the HTTP response sent from an endpoint. Contains the following fields:

status

The status code of the HTTP response.

body

The contents of the request body.

isAuditLog

A flag set to true to differentiate audit logs from other log types.

errors

A list of errors containing the name, message and potentially the stack field of the error. Only appears when status is failed.

9.2.2. Scaffolder events

Developer Hub audit logs can include the following scaffolder events:

ScaffolderParameterSchemaFetch

Tracks GET requests to the /v2/templates/:namespace/:kind/:name/parameter-schema endpoint which return template parameter schemas

ScaffolderInstalledActionsFetch

Tracks GET requests to the /v2/actions endpoint which grabs the list of installed actions

ScaffolderTaskCreation

Tracks POST requests to the /v2/tasks endpoint which creates tasks that the scaffolder executes

ScaffolderTaskListFetch

Tracks GET requests to the /v2/tasks endpoint which fetches details of all tasks in the scaffolder.

ScaffolderTaskFetch

Tracks GET requests to the /v2/tasks/:taskId endpoint which fetches details of a specified task :taskId

ScaffolderTaskCancellation

Tracks POST requests to the /v2/tasks/:taskId/cancel endpoint which cancels a running task

ScaffolderTaskStream

Tracks GET requests to the /v2/tasks/:taskId/eventstream endpoint which returns an event stream of the task logs of task :taskId

ScaffolderTaskEventFetch

Tracks GET requests to the /v2/tasks/:taskId/events endpoint which returns a snapshot of the task logs of task :taskId

ScaffolderTaskDryRun

Tracks POST requests to the /v2/dry-run endpoint which creates a dry-run task. All audit logs for events associated with dry runs have the meta.isDryLog flag set to true.

ScaffolderStaleTaskCancellation

Tracks automated cancellation of stale tasks

ScaffolderTaskExecution

Tracks the initiation and completion of a real scaffolder task execution (will not occur during dry runs)

ScaffolderTaskStepExecution

Tracks initiation and completion of a scaffolder task step execution

ScaffolderTaskStepSkip

Tracks steps skipped due to if conditionals not being met

ScaffolderTaskStepIteration

Tracks the step execution of each iteration of a task step that contains the each field.

9.2.3. Catalog events

Developer Hub audit logs can include the following catalog events:

CatalogEntityAncestryFetch

Tracks GET requests to the /entities/by-name/:kind/:namespace/:name/ancestry endpoint, which returns the ancestry of an entity

CatalogEntityBatchFetch

Tracks POST requests to the /entities/by-refs endpoint, which returns a batch of entities

CatalogEntityDeletion

Tracks DELETE requests to the /entities/by-uid/:uid endpoint, which deletes an entity

Note

If the parent location of the deleted entity is still present in the catalog, then the entity is restored in the catalog during the next processing cycle.
CatalogEntityFacetFetch

Tracks GET requests to the /entity-facets endpoint, which returns the facets of an entity

CatalogEntityFetch

Tracks GET requests to the /entities endpoint, which returns a list of entities

CatalogEntityFetchByName

Tracks GET requests to the /entities/by-name/:kind/:namespace/:name endpoint, which returns an entity matching the specified entity reference, for example, <kind>:<namespace>/<name>

CatalogEntityFetchByUid

Tracks GET requests to the /entities/by-uid/:uid endpoint, which returns an entity matching the unique ID of the specified entity

CatalogEntityRefresh

Tracks POST requests to the /entities/refresh endpoint, which schedules the specified entity to be refreshed

CatalogEntityValidate

Tracks POST requests to the /entities/validate endpoint, which validates the specified entity

CatalogLocationCreation

Tracks POST requests to the /locations endpoint, which creates a location

Note

A location is a marker that references other places to look for catalog data.
CatalogLocationAnalyze

Tracks POST requests to the /locations/analyze endpoint, which analyzes the specified location

CatalogLocationDeletion

Tracks DELETE requests to the /locations/:id endpoint, which deletes a location and all child entities associated with it

CatalogLocationFetch

Tracks GET requests to the /locations endpoint, which returns a list of locations

CatalogLocationFetchByEntityRef

Tracks GET requests to the /locations/by-entity endpoint, which returns a list of locations associated with the specified entity reference

CatalogLocationFetchById

Tracks GET requests to the /locations/:id endpoint, which returns a location matching the specified location ID

QueriedCatalogEntityFetch

Tracks GET requests to the /entities/by-query endpoint, which returns a list of entities matching the specified query