Getting started with Red Hat Developer Hub

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

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

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

In the Red Hat OpenShift cluster, navigate to the main page of the GitHub organization where you want to create the OAuth application.
Click Settings → Developer Settings → OAuth Apps → Register an application
Enter the application name as Developer Hub.
Add the following URL as the Homepage URL:

https://developer-hub-<NAMESPACE_NAME>.<OPENSHIFT_ROUTE_HOST>/
Add the following URL as Authorization callback URL:

https://developer-hub-<NAMESPACE_NAME>.<OPENSHIFT_ROUTE_HOST>/api/auth/github/handler/frame
Clear the Enable Device Flow checkbox.
Click Register application to create your OAuth application.
After creating the application, click Generate a new client secret and copy the generated client secret.
In OpenShift, click ConfigMaps.
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

Table 2. Environment variables
Key	Value
`GITHUB_OAUTH_CLIENT_ID`	Client ID from OAuth application
`GITHUB_OAUTH_CLIENT_SECRET`	Client Secret from OAuth application

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}

Click Save.
Navigate to the Helm tab and select Upgrade.
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

In the Red Hat OpenShift cluster, navigate to the main page of the GitHub organization where you want to create the OAuth application.
Click Settings → Developer Settings → GitHub Apps → New GitHub App.
Enter the application name as Developer Hub.
Add the following URL as the Homepage URL:

https://developer-hub-<NAMESPACE_NAME>.<OPENSHIFT_ROUTE_HOST>/
Add the following URL as Authorization callback URL:

https://developer-hub-<NAMESPACE_NAME>.<OPENSHIFT_ROUTE_HOST>/api/auth/github/handler/frame
Deselect Webhook URL → Active.
Under the Where can this GitHub App be installed? section, ensure that Only on this account is selected.
Click Register application.
After creating the application, click Generate a new client secret and copy the generated client secret.
Click Generate a private key at the bottom of the page and download the generated file.
In OpenShift, click ConfigMaps.

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:

In Red Hat OpenShift, go to the Secrets tab and click Create.
Select Key/value secret.
Enter Secret name as github-secrets.
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

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}

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

You have set up the GitHub integration. For more information, see Configuring GitHub integration.

Procedure

In the Developer perspective of the OpenShift Container Platform web console, go to the Helm tab.
Click the overflow menu on a Helm release and select Upgrade.
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
  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.

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.

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

You have set up the GitHub integration. For more information, see Configuring GitHub integration.

Procedure

In the Developer perspective of the OpenShift Container Platform web console, go to the Helm tab.
Click the overflow menu on a Helm release and select Upgrade.
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
  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.

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.

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:

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 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:

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 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:

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

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

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

fullLogo is the logo on the expanded (pinned) sidebar and expects a base64 encoded image.
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)
# ...

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

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

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.

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

The main primary color for the light color palette, for example, #ffffff or white
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
The background color for the default page theme for the light color palette, for example, #ffffff or white
The main primary color for the dark color palette, for example, #000000 or black
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
The background color for the default page theme for the dark color palette, for example, #000000 or black

Additional resources

Customizing the theme mode for your Developer Hub instance

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

The theme mode, for example, light or dark
The yaml header for the default page theme configuration
The color of the page header background, for example, #ffffff or white
The color of the text in the page header, for example, #000000 or black
The pattern on the page header, for example, wave, round, or none
The yaml header for a specific page theme configuration, for example, apis, home

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

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

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

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

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

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

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

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

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}

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

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 ref-audit-log-fields.adoc_assembly-audit-log
For a list of scaffolder events that a Developer Hub audit log can include, see ref-audit-log-scaffolder-events.adoc_assembly-audit-log

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

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.

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

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

Set enabled to true to use audit log file rotation. By default, it is set to false.
Absolute path to the log file. The specified directory is created automatically if it does not exist.
Default log file name format.
If no frequency is specified, then the default file rotation occurs daily at 00:00 local time.
Default date format.
Set utc to true to use UTC time for dateFormat instead of local time.
Sets a maximum file size limit for the audit log. In this example, the maximum size is 100m.
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.
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

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

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

3.2.1. Configuring GitHub authentication

3.2.2. Configuring GitHub integration

3.2.3. Enabling GitHub discovery in Red Hat Developer Hub

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

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

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

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

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

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

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

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

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

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

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

7.1. Customizing the theme mode for your Developer Hub instance

7.2. Customizing the branding logo of your Developer Hub instance

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

7.4. Customizing the application title for your Developer Hub instance

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

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

7.7. Customizing the font for your Developer Hub instance

7.8. Default Red Hat Developer Hub theme

7.8.1. Default Red Hat Developer Hub theme color palette

7.8.2. Default Red Hat Developer Hub page themes

7.9. Default Backstage theme

7.9.1. Default Backstage theme color palette

7.9.2. Default Backstage page themes

7.10. Custom component options for your Developer Hub instance

Chapter 8. ServiceNow Custom actions in Red Hat Developer Hub

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

8.2. Supported ServiceNow custom actions in Red Hat Developer Hub

8.2.1. ServiceNow custom actions

Chapter 9. Audit logs in Red Hat Developer Hub

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

9.2. Viewing audit logs in Developer Hub

9.2.1. Audit log fields

9.2.2. Scaffolder events

9.2.3. Catalog events

9.3. Audit log file rotation in Red Hat Developer Hub