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 Developer Hub application, database components, and Operator.

Table 2.1. Recommended sizing for running Red Hat Developer Hub

Components	Red Hat Developer Hub application	Red Hat Developer Hub database	Red Hat Developer Hub Operator
Central Processing Unit (CPU)	4 vCPU	2 vCPU	1 vCPU
Memory	16 GB	8 GB	1500 Mi
Storage size	2 GB	20 GB	50 Mi
Replicas	2 or more	3 or more	1 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: Red Hat Developer Hub

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

From the OpenShift Container Platform web console, select the ConfigMaps tab.
Click Create ConfigMap.
From Create ConfigMap page, select the YAML view option in Configure via and make changes to the file, if needed.
Click Create.
Go to the Helm tab to see the list of Helm releases.
Click the overflow menu on the Helm release that you want to use and select Upgrade.
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

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>.
From the Developer perspective in the OpenShift Container Platform web console, select the ConfigMaps view.
Click Create ConfigMap.
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:
        externalAccess:
            - type: legacy
              options:
                subject: legacy-default-config
                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.
Click Create.
Select the Secrets view.
Click Create Key/value Secret.
Create a secret named secrets-rhdh.
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")'
```
Click Create.
Select the Topology view.
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.

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

Click Save.
Navigate back to the Topology view and wait for the Red Hat Developer Hub pod to start.
Click the Open URL icon to use the Red Hat Developer Hub platform with the configuration changes.

Additional resources

For more information about roles and responsibilities in Developer Hub, see Role-Based Access Control (RBAC) in Red Hat Developer Hub.

Chapter 4. Bulk importing GitHub repositories

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.

Red Hat Developer Hub can automate GitHub repositories onboarding and track their import status.

4.1. Enabling and giving access to the Bulk Import feature

You can enable the Bulk Import feature for users and give them the necessary permissions to access it.

Prerequisites

You have configured GitHub integration.

Procedure

The Bulk Import plugins are installed but disabled by default. To enable the ./dynamic-plugins/dist/janus-idp-backstage-plugin-bulk-import-backend-dynamic and ./dynamic-plugins/dist/janus-idp-backstage-plugin-bulk-import plugins, edit your dynamic-plugins.yaml with the following content:
dynamic-plugins.yaml fragment
```
plugins:
  - package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-bulk-import-backend-dynamic
    disabled: false
  - package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-bulk-import
    disabled: false
```
See Installing and viewing dynamic plugins.
Configure the required bulk.import RBAC permission for the users who are not administrators as follows:
rbac-policy.csv fragment
```
p, role:default/bulk-import, bulk.import, use, allow
g, user:default/<your_user>, role:default/bulk-import
```
Note that only Developer Hub administrators or users with the bulk.import permission can use the Bulk Import feature. See Permission policies in Red Hat Developer Hub.

Verification

The sidebar displays a Bulk Import option.
The Bulk Import page shows a list of Added Repositories.

4.2. Importing multiple GitHub repositories

In Red Hat Developer Hub, you can select your GitHub repositories and automate their onboarding to the Developer Hub catalog.

Prerequisites

You have enabled the Bulk Import feature and gave access to it.

Procedure

Click Bulk Import in the left sidebar.
Click the Add button in the top-right corner to see the list of all repositories accessible from the configured GitHub integrations.
1. From the Repositories view, you can select any repository, or search for any accessible repositories. For each repository selected, a catalog-info.yaml is generated.
2. From the Organizations view, you can select any organization by clicking Select in the third column. This option allows you to select one or more repositories from the selected organization.
Click Preview file to view or edit the details of the pull request for each repository.
1. Review the pull request description and the catalog-info.yaml file content.
2. Optional: when the repository has a .github/CODEOWNERS file, you can select the Use CODEOWNERS file as Entity Owner checkbox to use it, rather than having the content-info.yaml contain a specific entity owner.
3. Click Save.
Click Create pull requests. At this point, a set of dry-run checks runs against the selected repositories to ensure they meet the requirements for import, such as:
1. Verifying that there is no entity in the Developer Hub catalog with the name specified in the repository catalog-info.yaml
2. Verifying that the repository is not empty
3. Verifying that the repository contains a .github/CODEOWNERS file if the Use CODEOWNERS file as Entity Owner checkbox is selected for that repository
  - If any errors occur, the pull requests are not created, and you see a Failed to create PR error message detailing the issues. To view more details about the reasons, click Edit.
  - If there are no errors, the pull requests are created, and you are redirected to the list of added repositories.
Review and merge each pull request that creates a catalog-info.yml file.

Verification

The Added repositories list displays the repositories you imported, each with an appropriate status: either Waiting for approval or Added.
For each Waiting for approval import job listed, there is a corresponding pull request adding the catalog-info.yaml file in the corresponding repository.

4.3. Managing the added repositories

You can oversee and manage the repositories that are imported to the Developer Hub.

Prerequisites

You have imported GitHub repositories.

Procedure

Click Bulk Import in the left sidebar to display all the current repositories that are being tracked as Import jobs, along with their status.
Added
The repository is added to the Developer Hub catalog after the import pull request is merged or if the repository already contained a catalog-info.yaml file during the bulk import. Note that it may take a few minutes for the entities to be available in the catalog.
Waiting for approval
There is an open pull request adding a catalog-info.yaml file to the repository. You can:
Click the pencil icon on the right to see details about the pull request or edit the pull request content right from Developer Hub.
Delete the Import job, this action closes the import PR as well.
To transition the Import job to the Added state, merge the import pull request from the Git repository.
Empty
Developer Hub is unable to determine the import job status because the repository is imported from other sources but does not have a catalog-info.yaml file and lacks any import pull request adding it.

Note

After an import pull request is merged, the import status is marked as Added in the list of Added Repositories, but it might take a few seconds for the corresponding entities to appear in the Developer Hub Catalog.
A location added through other sources (like statically in an app-config.yaml file, dynamically when enabling GitHub discovery, or registered manually using the "Register an existing component" page) might show up in the Bulk Import list of Added Repositories if the following conditions are met:
- The target repository is accessible from the configured GitHub integrations.
- The location URL points to a catalog-info.yaml file at the root of the repository default branch.

4.4. Understanding the Bulk Import audit Logs

The Bulk Import backend plugin adds the following events to the Developer Hub audit logs. See Audit Logs in Red Hat Developer Hub for more information on how to configure and view audit logs.

Bulk Import Events:

BulkImportUnknownEndpoint: Tracks requests to unknown endpoints.
BulkImportPing: Tracks GET requests to the /ping endpoint, which allows us to make sure the bulk import backend is up and running.
BulkImportFindAllOrganizations: Tracks GET requests to the /organizations endpoint, which returns the list of organizations accessible from all configured GitHub Integrations.
BulkImportFindRepositoriesByOrganization: Tracks GET requests to the /organizations/:orgName/repositories endpoint, which returns the list of repositories for the specified organization (accessible from any of the configured GitHub Integrations).
BulkImportFindAllRepositories: Tracks GET requests to the /repositories endpoint, which returns the list of repositories accessible from all configured GitHub Integrations.
BulkImportFindAllImports: Tracks GET requests to the /imports endpoint, which returns the list of existing import jobs along with their statuses.
BulkImportCreateImportJobs: Tracks POST requests to the /imports endpoint, which allows to submit requests to bulk-import one or many repositories into the Developer Hub catalog, by eventually creating import pull requests in the target repositories.
BulkImportFindImportStatusByRepo: Tracks GET requests to the /import/by-repo endpoint, which fetches details about the import job for the specified repository.
BulkImportDeleteImportByRepo: Tracks DELETE requests to the /import/by-repo endpoint, which deletes any existing import job for the specified repository, by closing any open import pull request that could have been created.

Example bulk import audit logs

{
  "actor": {
    "actorId": "user:default/myuser",
    "hostname": "localhost",
    "ip": "::1",
    "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
  },
  "eventName": "BulkImportFindAllOrganizations",
  "isAuditLog": true,
  "level": "info",
  "message": "'get /organizations' endpoint hit by user:default/myuser",
  "meta": {},
  "plugin": "bulk-import",
  "request": {
    "body": {},
    "method": "GET",
    "params": {},
    "query": {
      "pagePerIntegration": "1",
      "sizePerIntegration": "5"
    },
    "url": "/api/bulk-import/organizations?pagePerIntegration=1&sizePerIntegration=5"
  },
  "response": {
    "status": 200
  },
  "service": "backstage",
  "stage": "completion",
  "status": "succeeded",
  "timestamp": "2024-08-26 16:41:02"
}

Chapter 5. 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.

5.1. Using hosted JSON files to provide data to the Home page

Prerequisites

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

For more information, see Installing Red Hat Developer Hub on OpenShift Container Platform.

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

5.2. Using a dedicated service to provide data to the Home 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. For more information, see Installing Red Hat Developer Hub on OpenShift Container Platform with the Helm chart.

Procedure

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

From the Developer perspective in the Red Hat OpenShift Container Platform web console, click +Add > Import from Git.
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.
On the General tab, enter red-hat-developer-hub-customization-provider in the Name field and click Create.
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.
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.
Replace the HOMEPAGE_DATA_URL by adding the URL to rhdh-secrets or by directly replacing it in your custom ConfigMap.
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 6. 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.

6.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. For more information, see Installing Red Hat Developer Hub on OpenShift Container Platform.

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

6.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. For more information, see Installing Red Hat Developer Hub on OpenShift Container Platform with the Helm chart.

Procedure

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

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.
Delete the Developer Hub pod to ensure that the new configurations are loaded correctly.

Chapter 7. 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 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.

7.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. For more information, see Installing Red Hat Developer Hub on OpenShift Container Platform.

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

7.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. For more information, see Installing Red Hat Developer Hub on OpenShift Container Platform.

Procedure

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

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.
Delete the Developer Hub pod to ensure that the new configurations are loaded correctly.

Chapter 8. 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 Section 8.8, “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 Section 8.9, “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).

8.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

From the Developer Hub web console, click Settings.
From the Appearance panel, click LIGHT THEME, DARK THEME, or AUTO to change the theme mode.

8.2. Customizing the branding logo of your Developer Hub instance

You can customize the branding logo of your Developer Hub instance by configuring the branding section the app-config-rhdh.yaml file, as shown in the following example:

app:
  branding:
    fullLogo: ${BASE64_EMBEDDED_FULL_LOGO} 1
    iconLogo: ${BASE64_EMBEDDED_ICON_LOGO} 2

where:

1: fullLogo is the logo on the expanded (pinned) sidebar and expects a base64 encoded image.
2: iconLogo is the logo on the collapsed (unpinned) sidebar and expects a base64 encoded image.

You can also customize the width of the branding logo by setting a value for the fullLogoWidth field in the branding section, as shown in the following example:

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

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

8.3. Customizing the sidebar menu items for your Developer Hub instance

The sidebar menu in Red Hat Developer Hub consists of two main parts:

Main menu items: These items are the static menu items that form the core navigation structure of sidebar. These menu items remain consistent and are predefined.
Dynamic plugin menu items: These items are displayed beneath the main menu and can be customized based on the plugins installed. The main menu items section is dynamic and can change based on your preferences and installed plugins.

Procedure

Customize the main menu items using the following steps:
1. Open the app-config-rhdh.yaml file.
2. To customize the order and parent-child relationships for the main menu items, use the dynamicPlugins.frontend.default.main-menu-items.menuItems field.
3. For dynamic plugin menu items, use the dynamicPlugins.frontend.<package_name>.menuItems field.
Example app-config-rhdh.yaml file
```
dynamicPlugins:
  frontend:
    <package_name>: # same as `scalprum.name` key in plugin's `package.json`
      menuItems: # optional, allows you to configure plugin menu items in the main sidebar navigation
        <menu_item_name>: # unique name in the plugin menu items list 1
          icon: home | group | category | extension | school | _<your_icon>_  2
          title: My Plugin Page # optional, same as `menuItem.text` in `dynamicRoutes` 3
          priority: 10 # optional, defines the order of menu items in the sidebar 4
          parent: favorites # optional, defines parent-child relationships for nested menu items 5
```
You can modify the fields in the previous example to configure the desired order and parent-child relationships of the sidebar menu items.
1
This attribute represents a unique name in the main sidebar navigation. It can denote either a standalone menu item or a parent menu item. If this attribute represents a plugin menu item, the name of the attribute must match with the corresponding path in dynamicRoutes. For example, if dynamicRoutes defines path: /my-plugin, then menu_item_name must be defined as my-plugin.
For more complex, multi-segment paths such as path: /metrics/users/info, the menu_item_name must use dot notation to represent the full path, for example, metrics.users.info. Trailing and leading slashes in paths are ignored. For example, path: /docs results in menu_item_name: docs, and path: /metrics/users results in menu_item_name: metrics.users.
2
This optional attribute specifies the icon for the menu item. You can use default icons or extend the icon set with dynamic plugins. Developer Hub also provides additional icons in its internal library, such as:
Home Icon in the internal library

dynamicPlugins: frontend: <package_name>: menuItems: <menu_item_name>: icon: home
Similarly, the internal library includes icons for group, category, extension, and school. If the icon is already defined in the dynamicRoutes configuration under menuItem.icon, it can be removed from the in the menuItems configuration. Also, both SVG and HTML image icons are supported. For example:
Example SVG icon

icon: <svg width="20px" height="20px" viewBox="0 0 512 512" xmlns="http://www.w3.org/2000/svg" fill="#ffffff">...</svg>
Example image icon

icon: https://img.icons8.com/ios-glyphs/20/FFFFFF/shop.png
3
This optional attribute specifies the title of the menu item. It can be removed if the title is already specified in the dynamicRoutes configuration under menuItem.text.
4
This optional attribute sets the order in which menu items appear in the sidebar. The default priority is 0, which places the item at the bottom of the list. A higher priority value places the item higher in the sidebar. You can define this attribute for each section.
5
This optional attribute specifies the parent menu item under which the current item is nested. If this attribute is used, the parent menu item must be defined elsewhere in the menuItems configuration of any enabled plugin. You can define this attribute for each section.
Example menuItems configuration
```
dynamicPlugins:
  frontend:
    <package_name>:
      dynamicRoutes:
        - path: /my-plugin
          module: CustomModule
          importName: FooPluginPage
          menuItem:
            icon: fooIcon
            text: Foo Plugin Page
      menuItems:
        my-plugin: # matches `path` in `dynamicRoutes`
          priority: 10 # controls order of plugins under the parent menu item
          parent: favorites # nests this plugin under the `favorites` parent menu item
        favorites: # configuration for the parent menu item
          icon: favorite # icon from RHDH system icons
          title: Favorites # title for the parent menu item
          priority: 100 # controls the order of this top-level menu item
```

To ensure that a menu item is identified as a main menu item, you must add default. prefix to its key. For example:

Example configuration of main menu items in sidebar navigation

dynamicPlugins:
  frontend:
    default.main-menu-items: # key for configuring static main menu items
      default.<menu_item_name>: # key of the menu item configuration. `default.` prefix is required for a main menu item key 1
        parent: my_menu_group # optional, specifies the parent menu item for this item
        priority: 10 # optional, specifies the order of this menu item within its menu level
      default.<menu_group_parent_item_name>: # must be configured if it is specified as the parent of any menu items. `default.` prefix is required for a main menu item key
        icon: my_menu_group_icon # required for parent menu items, defines the icon for the menu group
        title: my_menu_group_title # required for parent menu items, defines the icon for the menu group
        priority: 100 # optional, specifies the order of the parent menu item in the sidebar

1: The default. prefix identifes an item as a main menu item. You can add the default. prefix to both individual menu items or parent menu group configuration, such as default.<menu_group_parent_item_name> in the previous example.

Note

The default priority of main menu items determines their order in the sidebar. You can customize the order of the static main menu items by adjusting their priority values. Ensure that the priority and title of each item is clear to facilitate easy reordering.

8.4. 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
# ...

8.5. 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

Section 8.1, “Customizing the theme mode for your Developer Hub instance”

8.6. 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

8.7. 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
# ...

8.8. 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.

8.8.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"

8.8.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"

8.9. 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.

8.9.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"

8.9.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

8.10. 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 9. 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

9.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. For more information about installing the Developer Hub, see Installing Red Hat Developer Hub on OpenShift Container Platform with the Helm chart.
You have created a project in the Developer Hub.

Procedure

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.

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}

9.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

9.2.1. ServiceNow custom actions

[GET] servicenow:now:table:retrieveRecord

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

Table 9.1. 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 9.2. 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 9.3. 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 9.4. 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 9.5. 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.6. 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 9.7. 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 9.8. 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 9.9. 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 9.10. 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 9.11. 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 10. 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

For more information about logging in OpenShift Container Platform, see About Logging
For a complete list of fields that a Developer Hub audit log can include, see Section 10.2.1, “Audit log fields”
For a list of scaffolder events that a Developer Hub audit log can include, see Section 10.2.2, “Scaffolder events”

10.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.

10.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

From the Developer perspective of the OpenShift Container Platform web console, click the Topology tab.
From the Topology view, click the pod that you want to view audit log data for.
From the pod panel, click the Resources tab.
From the Pods section of the Resources tab, click View logs.
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.

10.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.

10.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.

10.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

10.3. Audit log file rotation in Red Hat Developer Hub

Logging to a rotating file in Red Hat Developer Hub is helpful for persistent storage of audit logs.

Persistent storage ensures that the file remains intact even after a pod is restarted. Audit log file rotation creates a new file at regular intervals, with only new data being written to the latest file.

Default settings

Audit logging to a rotating file is disabled by default. When it is enabled, the default behavior changes to:

Rotate logs at midnight (local system timezone).
Log file format: redhat-developer-hub-audit-%DATE%.log.
Log files are stored in /var/log/redhat-developer-hub/audit.
No automatic log file deletion.
No gzip compression of archived logs.
No file size limit.

Audit logs are written in the /var/log/redhat-developer-hub/audit directory.

Log file names: Audit log file names are in the following format:

redhat-developer-hub-audit-%DATE%.log

where %DATE% is the format specified in auditLog.rotateFile.dateFormat. You can customize file names when you configure file rotation.

File rotation date and frequency

Supported auditLog.rotateFile.frequency options include:

daily: Rotate daily at 00:00 local time
Xm: Rotate every X minutes (where X is a number between 0 and 59)
Xh: Rotate every X hours (where X is a number between 0 and 23)
test: Rotate every 1 minute
custom: Use dateFormat to set the rotation frequency (default if frequency is not specified)

If frequency is set to Xh, Xm or test, the dateFormat setting must be configured in a format that includes the specified time component. Otherwise, the rotation might not work as expected.

For example, use dateFormat: 'YYYY-MM-DD-HH for hourly rotation, and dateFormat: 'YYYY-MM-DD-HH-mm for minute rotation.

Example minute rotation:

auditLog:
  rotateFile:
    # If you want to rotate the file every 17 minutes
    dateFormat: 'YYYY-MM-DD-HH-mm'
    frequency: '17m'

The dateFormat setting configures both the %DATE% in logFileName and the file rotation frequency if frequency is set to custom. The default format is YYYY-MM-DD, meaning daily rotation. Supported values are based on Moment.js formats.

If the frequency is set to custom, then rotations take place when the date string, which is represented in the specified dateFormat, changes.

Archive and delete: By default, log files are not archived or deleted.
Enable and configure audit file rotation: If you are an administrator of Developer Hub, you can enable file rotation for audit logs, and configure the file log location, name format, frequency, log file size, retention policy, and archiving.

Example audit log file rotation configuration

auditLog:
  rotateFile:
    enabled: true 1
    logFileDirPath: /custom-path 2
    logFileName: custom-audit-log-%DATE%.log 3
    frequency: '12h' 4
    dateFormat: 'YYYY-MM-DD' 5
    utc: false 6
    maxSize: 100m 7
    maxFilesOrDays: 14 8
    zippedArchive: true 9

1: Set enabled to true to use audit log file rotation. By default, it is set to false.
2: Absolute path to the log file. The specified directory is created automatically if it does not exist.
3: Default log file name format.
4: If no frequency is specified, then the default file rotation occurs daily at 00:00 local time.
5: Default date format.
6: Set utc to true to use UTC time for dateFormat instead of local time.
7: Sets a maximum file size limit for the audit log. In this example, the maximum size is 100m.
8: If set to number of files, for example 14, then it deletes the oldest log when there are more than 14 log files. If set to number of days, for example 5d, then it deletes logs older than 5 days.
9: Archive and compress rotated logs using gzip. The default value is false.

Note

By default, log files are not archived or deleted. If log deletion is enabled, then a .<sha256 hash>-audit.json is generated in the directory where the logs are to track generated logs. Any log file not contained in the directory is not subject to automatic deletion.
A new .<sha256 hash>-audit.json file is generated each time the backend starts, which causes previous audit logs to stop being tracked or deleted, except for those still in use by the current backend.

Getting started with Red Hat Developer Hub

Preface

Red Hat Developer Hub support

Chapter 1. Overview of Red Hat Developer Hub

Chapter 2. Sizing requirements for Red Hat Developer Hub

Chapter 3. Supported configurations for Red Hat Developer Hub

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

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

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

Chapter 4. Bulk importing GitHub repositories

4.1. Enabling and giving access to the Bulk Import feature

4.2. Importing multiple GitHub repositories

4.3. Managing the added repositories

4.4. Understanding the Bulk Import audit Logs

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

5.1. Using hosted JSON files to provide data to the Home page

5.2. Using a dedicated service to provide data to the Home page

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

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

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

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

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

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

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

8.1. Customizing the theme mode for your Developer Hub instance

8.2. Customizing the branding logo of your Developer Hub instance

8.3. Customizing the sidebar menu items for your Developer Hub instance

8.4. Customizing the application title for your Developer Hub instance

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

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

8.7. Customizing the font for your Developer Hub instance

8.8. Default Red Hat Developer Hub theme

8.8.1. Default Red Hat Developer Hub theme color palette

8.8.2. Default Red Hat Developer Hub page themes

8.9. Default Backstage theme

8.9.1. Default Backstage theme color palette

8.9.2. Default Backstage page themes

8.10. Custom component options for your Developer Hub instance

Chapter 9. ServiceNow Custom actions in Red Hat Developer Hub

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

9.2. Supported ServiceNow custom actions in Red Hat Developer Hub

9.2.1. ServiceNow custom actions

Chapter 10. Audit logs in Red Hat Developer Hub

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

10.2. Viewing audit logs in Developer Hub

10.2.1. Audit log fields

10.2.2. Scaffolder events

10.2.3. Catalog events

10.3. Audit log file rotation in Red Hat Developer Hub

Legal Notice