Red Hat Developer Hub 1.8

Integrating Red Hat Developer Hub with GitHub

Configuring integration to the GitHub Git provider in Red Hat Developer Hub

Red Hat Customer Content Services

Abstract

As a Red Hat Developer Hub (RHDH) platform engineer, you can integrate RHDH with the GitHub Git provider.

1. Enabling GitHub repository discovery

Consider configuring Developer Hub to discover and ingest your GitHub repositories automatically. If a repository contains a catalog-info.yaml file, Developer Hub ingests the repository into the catalog as a component.

Prerequisites

Procedure

  1. To allow Developer Hub to access the GitHub API, create a GitHub App. Opt for a GitHub App instead of an OAuth app to use fine-grained permissions, gain more control over which repositories the application can access, and use short-lived tokens.

    1. Register a GitHub App with the following configuration:

      GitHub App name
      Enter a unique name identifying your GitHub App, such as integrating-with-rhdh-<GUID>.
      Homepage URL
      Enter your Developer Hub URL: https://<my_developer_hub_domain>.
      Authorization callback URL
      Enter your Developer Hub authentication backend URL: https://<my_developer_hub_domain>/api/auth/github/handler/frame.
      Webhook
      Clear "Active", as this is not needed for authentication and catalog providers.
      App permissions

      Select permissions to define the level of access for the app. Adapt permissions to your needs:

      Reading software components
      Contents
      Read-only
      Commit statuses
      Read-only
      Reading organization data
      Members
      Read-only
      Publishing software templates

      Set permissions if you intend to use the same GitHub App for software templates.

      Administration
      Read & write (for creating repositories)
      Contents
      Read & write
      Metadata
      Read-only
      Pull requests
      Read & write
      Issues
      Read & write
      Workflows
      Read & write (if templates include GitHub workflows)
      Variables
      Read & write (if templates include GitHub Action Repository Variables)
      Secrets
      Read & write (if templates include GitHub Action Repository Secrets)
      Environments
      Read & write (if templates include GitHub Environments)
      Organization permissions
      Members
      Read-only
      Where can this GitHub App be installed?
      Select Only on this account.
    2. In the GeneralClients secrets section, click Generate a new client secret.
    3. In the GeneralPrivate keys section, click Generate a private key.
    4. In the Install App tab, choose an account to install your GitHub App on.
    5. Save the following values for the next step:

      • App ID
      • Client ID
      • Client secret
      • Private key
  2. To add your GitHub credentials to Developer Hub, add the following key/value pairs to your Developer Hub secrets. You can use these secrets in the Developer Hub configuration files by using their respective environment variable name.

    GITHUB_INTEGRATION_APP_ID
    Enter the saved App ID.
    GITHUB_INTEGRATION_CLIENT_ID
    Enter the saved Client ID.
    GITHUB_INTEGRATION_CLIENT_SECRET
    Enter the saved Client Secret.
    GITHUB_INTEGRATION_HOST_DOMAIN
    Enter the GitHub host domain: github.com.
    GITHUB_INTEGRATION_ORGANIZATION
    Enter your GitHub organization name, such as `<your_github_organization_name>'.
    GITHUB_INTEGRATION_PRIVATE_KEY_FILE
    Enter the saved Private key.
  3. Enable the plugin-catalog-backend-module-github plugin in your dynamic-plugins.yaml file.

    This plugin discovers catalog entities by scanning repositories within a GitHub organization for catalog-info.yaml files. It provides an automated alternative to manually registering components via catalog.locations. When a repository contains a catalog-info.yaml file, the entity is ingested into the catalog as a component.

    dynamic-plugins.yaml file fragment

    plugins:
      - package: './dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github'
        disabled: false

  4. Configure the GitHub integration, by adding the catalog.providers.github and the integrations.github sections to your custom Developer Hub app-config.yaml configuration file:

    app-config.yaml file fragment with mandatory fields to enable GitHub integration

    catalog:
      providers:
        github:
          providerId:
            organization: "${GITHUB_INTEGRATION_ORGANIZATION}"
            schedule:
              frequency:
                minutes: 30
              initialDelay:
                seconds: 15
              timeout:
                minutes: 15
    integrations:
      github:
        - host: ${GITHUB_INTEGRATION_HOST_DOMAIN}
          apps:
            - appId: ${GITHUB_INTEGRATION_APP_ID}
              clientId: ${GITHUB_INTEGRATION_CLIENT_ID}
              clientSecret: ${GITHUB_INTEGRATION_CLIENT_SECRET}
              privateKey: |
                ${GITHUB_INTEGRATION_PRIVATE_KEY_FILE}

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

2.1. Input parameters for Bulk Import Scaffolder template

As an administrator, you can use the Bulk Import plugin to run a Scaffolder template task with specified parameters, which you must define within the template.

The Bulk Import plugin analyzes Git repository information and provides the following parameters for the Scaffolder template task:

repoUrl

Normalized repository URL in the following format:

  ${gitProviderHost}?owner=${owner}&repo=${repository-name}
name
The repository name.
organization
The repository owner, which can be a user nickname or organization name.
branchName
The proposed repository branch. By default, the proposed repository branch is bulk-import-catalog-entity.
targetBranchName
The default branch of the Git repository.
gitProviderHost
The Git provider host parsed from the repository URL. You can use this parameter to write Git-provider-agnostic templates.

Example of a Scaffolder template:

parameters:
  - title: Repository details
    required:
      - repoUrl
      - branchName
      - targetBranchName
      - name
      - organization
    properties:
      repoUrl:
        type: string
        title: Repository URL (Backstage format)
        description: github.com?owner=Org&repo=repoName
      organization:
        type: string
        title: Owner of the repository
      name:
        type: string
        title: Name of the repository
      branchName:
        type: string
        title: Branch to add the catalog entity to
      targetBranchName:
        type: string
        title: Branch to target the PR/MR to
      gitProviderHost:
        type: string
        title: Git provider host

2.2. Setting up a custom Scaffolder workflow for Bulk Import

As an administrator, you can create a custom Scaffolder template in line with the repository conventions of your organization and add the template into the Red Hat Developer Hub catalog for use by the Bulk Import plugin on multiple selected repositories.

You can define various custom tasks, including, but not limited to the following:

  • Importing existing catalog entities from a repository
  • Creating pull requests for cleanup
  • Calling webhooks for external system integration

Prerequisites

  • You created a custom Scaffolder template for the Bulk Import plugin.
  • You have run your RHDH instance with the following environment variable enabled to allow the use of the Scaffolder functionality:

    export NODE_OPTIONS=--no-node-snapshot

Procedure

  • Configure your app-config.yaml configuration to instruct the Bulk Import plugin to use your custom template as shown in the following example:

    bulkImport:
      importTemplate: <your_template_entity_reference_or_template_name>
      importAPI: `open-pull-requests` | `scaffolder`;

    where:

    importTemplate:
    Enter your Scaffolder template entity reference.
    importAPI
    Set the API to 'scaffolder' to trigger the defined workflow for high-fidelity automation. This field defines the import workflow and currently supports two following options:
    open-pull-requests
    This is the default import workflow, which includes the logic for creating pull requests for every selected repository.
    scaffolder

    This workflow uses an import scenario defined in the Scaffolder template to create import jobs. Select this option to use the custom import scenario defined in your Scaffolder template.

    Optional: You can direct the Bulk Import plugin to hand off the entire list of selected repositories to a custom Orchestrator workflow.

    Important

    The Scaffolder template must be generic and not specific to a single repository if you want your custom Scaffolder template to run successfully for every repository in the bulk list.

Verification

  • The Bulk Import plugin runs the custom Scaffolder template for the list of repositories using the /task-imports API endpoint.

2.3. Data handoff and custom workflow design

When you configure the Bulk Import plugin by setting the importAPI field to scaffolder, the Bulk Import Backend passes all necessary context directly to the Scaffolder API.

As an administrator, you can define the Scaffolder template workflow and structure the workflow to do the following:

Define template parameters to consume input
Structure the Scaffolder template to receive the repository data as template parameters for the current workflow run. The template must be generic, and not specific to a single repository, so that it can successfully run for every repository in the bulk list.
Automate processing for each repository
Implement the custom logic needed for a single repository within the template. The Orchestrator iterates through the repository list, launching the template once for each repository and passes only the data for that single repository to the template run. This allows you to automate tasks such as creating the catalog-info.yaml, running compliance checks, or registering the entity with the catalog.

Legal Notice

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