Procedure

1. The Bulk Import plugins are installed but disabled by default. To enable the ./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import-backend-dynamic and ./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import plugins, edit your dynamic-plugins.yaml with the following content:

   plugins:
     - package: ./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import-backend-dynamic
       disabled: false
     - package: ./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import
       disabled: false

   See Installing and viewing plugins in Red Hat Developer Hub.

2. Configure the required bulk.import RBAC permission for the users who are not administrators as shown in the following code:

   rbac-policy.csv fragment

   p, role:default/bulk-import, bulk.import, use, allow
   g, user:default/<your_user>, role:default/bulk-import

   Note that only Developer Hub administrators or users with the bulk.import permission can use the Bulk Import feature. See Permission policies in Red Hat Developer Hub.

Verification

1. The sidebar displays a Bulk Import option.
2. The Bulk Import page shows a list of added GitHub repositories and GitLab projects.

Procedure

1. Click Bulk Import in the Developer Hub left sidebar.

2. If your RHDH instance has multiple source control tools configured, select GitHub from the Source control tool list.

   The interface displays GitHub repositories that your authenticated user account can access, excluding repositories already present in the catalog.

3. Select the repositories to import, and click Add.

   Developer Hub creates a pull request in each selected repository to add the required catalog-info.yaml file using your GitHub credentials.

4. For each repository to import, click PR to review and merge the changes in GitHub.

Verification

1. Click Bulk Import in the Developer Hub left sidebar.
2. Verify that each imported GitHub repository in the Selected repositories list has the status Waiting for approval or Imported.

3. For each Waiting for approval repository, click the pull request link to review and merge the catalog-info.yaml file in the corresponding repository.

   The pull request is created using your GitHub user account, ensuring proper attribution in the repository history.

Procedure

1. Access your Developer Hub backend logs where audit log events are recorded.

2. Review the following Bulk Import audit log events to monitor repository operations:

   BulkImportUnknownEndpoint

   Tracks requests to unknown endpoints.

   BulkImportPing

   Tracks GET requests to the /ping endpoint, which allows us to make sure the bulk import backend is up and running.

   BulkImportFindAllOrganizations

   Tracks GET requests to the /organizations endpoint, which returns the list of organizations accessible from all configured GitHub Integrations.

   BulkImportFindRepositoriesByOrganization

   Tracks GET requests to the /organizations/:orgName/repositories endpoint, which returns the list of repositories for the specified organization (accessible from any of the configured GitHub Integrations).

   BulkImportFindAllRepositories

   Tracks GET requests to the /repositories endpoint, which returns the list of repositories accessible from all configured GitHub Integrations.

   BulkImportFindAllImports

   Tracks GET requests to the /imports endpoint, which returns the list of existing import jobs along with their statuses.

   BulkImportCreateImportJobs

   Tracks POST requests to the /imports endpoint, which allows to submit requests to bulk-import one or many repositories into the Developer Hub catalog, by eventually creating import pull requests in the target repositories.

   BulkImportFindImportStatusByRepo

   Tracks GET requests to the /import/by-repo endpoint, which fetches details about the import job for the specified repository.

   BulkImportDeleteImportByRepo

   Tracks DELETE requests to the /import/by-repo endpoint, which deletes any existing import job for the specified repository, by closing any open import pull request that could have been created.

   Example audit log output:

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

Procedure

1. In your Red Hat Developer Hub navigation menu, click Catalog.

2. Find the software component that you want to edit, under Actions, click the Edit icon.

   Note

   This action redirects you to the YAML file on GitHub.

3. On your remote repository UI, update your YAML file.

   Note

   After you merge your changes, the updated metadata in the Software Catalog is displayed after some time.

Procedure

1. In your Red Hat Developer Hub navigation menu, click Catalog.
2. On the Catalog page, click the Kind drop-down list.

3. Select the Kind you want to filter by, such as Component, API, or Template.

   Note

   The available filter lists change based on the Kind you select, showing options relevant to that entity type.

Procedure

1. In your Red Hat Developer Hub navigation menu, click Catalog.
2. In the Search field, enter a component name, description, or keyword that you are looking for.

Procedure

1. In your Red Hat Developer Hub navigation menu, click Catalog.

2. Find the software component that you want to view, under Actions, click the View icon.

   Note

   These steps redirect you to the YAML file on your remote repository.

Procedure

1. In the Red Hat Developer Hub navigation menu, select Catalog.
2. Locate the components you want to add as a favorite.
3. In the Actions column for that component, click the Add to favorites (star) icon.

Procedure

1. On the Red Hat Developer Hub navigation menu, click Catalog > Self-service or in the Global Header, click Create (+).
2. On the Self-service page, locate the Templates you want to use and click Choose to start the scaffolding process.
3. Follow the wizard instructions to enter the required project details.

4. In the Review step, verify your parameters and click Create.

   The scaffolding process begins. You can monitor the progress in the logs or click Cancel to stop the operation.

Procedure

1. In the Red Hat Developer Hub navigation menu, click Catalog > Self-service.
2. In the Search field, enter the name for the Software Template.
3. Optional: To refine the results, select a category from the Category list.

Procedure

1. Open your RHDH app-config.yaml configuration file.

2. In the catalog.rules section, add a rule to allow Templates kinds, as shown in the following example:

   # ...
   catalog:
     rules:
       - allow: [Template]
     locations:
       - type: url
         target: https://<repository_url/template-name>.yaml
   # ...

   where:

   catalog.rules.allow

   Specify the Template rule to allow new Software Templates in the catalog.

   catalog.locations.type

   Specify the url type when importing templates from a repository (for example, GitHub or GitLab).

   catalog.locations.target

   Specify the full URL to the template file.

Verification

1. In the Red Hat Developer Hub navigation menu, click Catalog.
2. From the Kind list, select Template.
3. Verify that the Template list displays your template.

Procedure

1. Optional: To see the skills available in the pack before you install, run the following command:

   npx skills add redhat-developer/rhdh-users-skill-pack --list

2. To install only the rhdh-templates skill, run the following command:

   npx skills add redhat-developer/rhdh-users-skill-pack --skill rhdh-templates

   To install the full skill pack, omit the --skill flag.

3. Optional: To target a specific agent, add the -a flag. For example:

   npx skills add redhat-developer/rhdh-users-skill-pack -a claude-code

Procedure

1. Ask your agent to run the init command from your target directory to check your tools, scaffold the template repository layout, and create the root location.yaml.
2. Optional: Ask your agent to also check connectivity to a running instance, and provide the instance URL.

3. Review the reported results, including any missing tools, the scaffolded paths, and the connectivity status.

   Note

   For the recommended development loop, install djlint so that local validation can lint Nunjucks in skeleton files. If a running instance is unreachable, local authoring and validation still work.

Verification

1. The templates/ directory exists and has at least one template folder.
2. A root location.yaml exists with the target ./templates/**/template.yaml.
3. The init script exits with code 0 (ready) or 1 (layout created, but optional tools or RHDH are unavailable).

Procedure

1. Ask your agent to templatize the codebase, specifying the source path. The skill runs a deterministic analyzer to detect the project type and candidate literals.
2. Review the candidate table that the skill presents. For each value, choose to parameterize it, keep it literal, or skip it. Parameterize identity values such as component name and owner; keep framework defaults literal.
3. Confirm the parameter mapping. Only after your confirmation does the skill create the skeleton/ directory, copy your source files, and replace confirmed values with ${{ values.<param> }} placeholders.
4. Confirm that the skill generates template.yaml with your parameters and a typical fetch:template, publish, and catalog:register step sequence.
5. Ask your agent to register the template by generating or updating the root location.yaml.

Verification

1. The templates/<name>/ directory has template.yaml and a skeleton/ directory, and the root location.yaml registers the template.
2. Skeleton files reference ${{ values.* }}, not ${{ parameters.* }}.
3. Local validation reports zero critical findings. See Validate a software template locally.

Procedure

1. Ask your agent to create a template. When prompted, provide the golden path the template enables, the target entity type, the required form fields, the steps to include, and your source control provider.
2. Review the reference examples that the skill suggests for your stack. You can mirror an example’s step sequence or start from the bundled minimal template.
3. Confirm that the skill builds the template directory with template.yaml, a skeleton/ directory, and an optional README.md. In skeleton files, values use the ${{ values.* }} prefix, which the fetch:template action requires.
4. Ask your agent to register the template by generating or updating the root location.yaml.

Verification

1. The template.yaml is a valid v1beta3 template with parameters, steps, and outputs appropriate to your use case.
2. The skeleton/ directory has at least one templated file, and location.yaml lists the new template.
3. Local validation and gotcha checks report zero critical findings. See Validate a software template locally.

Procedure

1. Ask your agent to validate your template directory, including the root location.yaml.
2. Ask your agent to lint Nunjucks in the skeleton files.
3. Ask your agent to auto-fix common issues, such as missing {% raw %} blocks or wrong action ID casing.
4. Address any remaining findings manually, then ask your agent to validate the template again.

Verification

1. Validation reports ok: true with a critical count of 0. Critical findings, such as a wrong apiVersion or invalid action casing, cause failures in the Template Editor.
2. You reviewed all warnings and decided whether to fix them before merging.

Procedure

1. Ask your agent to list the Scaffolder actions installed on your instance to confirm the exact action IDs used in your template.
2. Create a JSON file of sample parameter values that match spec.parameters. Use fake data, not real tokens or production identifiers.
3. Ask your agent to run a dry-run of the template against your instance, and provide the sample values.

Verification

1. The dry-run completes with exit code 0.
2. The log shows the expected steps, especially fetch:template, and reports the generated file count.