Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 4. About Software Templates


Software Templates in Red Hat Developer Hub provide a streamlined way to create software components and publish them to different version control repositories such as Git. Platform engineers create and maintain Software Templates in Red Hat Developer Hub.

4.1. Versioning a Software Template in Red Hat Developer Hub

As a platform administrator, you can version Software Templates by using the existing custom actions catalog:scaffolded-from and catalog:template:version within the Scaffolder backend module. By using these custom actions, you can track the Scaffolder template version and the corresponding version of the entities created from it, which improves lifecycle management.

Prerequisites

  • You have administrator rights to Red Hat Developer Hub.
  • The following dynamic plugins are enabled in your Backstage or my-rhdh-app-config file:

    • backstage-community-plugin-catalog-backend-module-scaffolder-relation-processor-dynamic
    • backstage-plugin-notifications
    • backstage-plugin-notifications-backend-dynamic

Procedure

To add versioning to a Software Template yaml file, complete the following steps:

  1. Make sure the required plugins are enabled in your RHDH my-rhdh-app-config file or the Backstage custom resource (CR):

    global:
      dynamic:
        plugins:
          - package: ./dynamic-plugins/dist/backstage-community-plugin-catalog-backend-module-scaffolder-relation-processor-dynamic
            disabled: false
          - package: ./dynamic-plugins/dist/backstage-plugin-notifications
            disabled: false
          - package: ./dynamic-plugins/dist/backstage-plugin-notifications-backend-dynamic
            disabled: false
    Copy to Clipboard Toggle word wrap
  2. Modify the Software Template that you want to update.
  3. Complete one or both of the following tasks:

    • Include the annotation in your template: Add the backstage.io/template-version annotation in your template metadata. When this annotation is present, it is automatically used to annotate your catalog entity and display a default version value.
    • Pass the annotation as input to the action: This method takes precedence over the annotation in the template itself and allows the user running the template to specify the version.
    # ...
    - id: version-templateRef
      name: Append the version of this template to the entityRef
      action: catalog:template:version
      input:
        annotations:
          backstage.io/template-version: ${{ parameters.version }}
    # ...
    Copy to Clipboard Toggle word wrap

Verification

  1. Create a catalog component using the updated Software Template. This step creates a new component in Backstage and optionally, pushes files to an external repository (For example, GitHub, GitLab).
  2. Check the component in the Catalog UI.

    1. On the Catalog page, locate the newly created catalog component.
    2. Verify that the backstage.io/template-version annotation is present in the entity. You can use INSPECT ENTITY and select YAML Raw or JSON Raw view to find the annotation in the component definition.
  3. Only if you have published the catalog component: Check the component file in the repository.

    1. If VIEW SOURCE is present in your UI: Click VIEW SOURCE to open the stored component file in the repository.
    2. Locate the file manually and verify that the backstage.io/template-version annotation is present.

As a platform engineer, you can enable notification alerts for template version updates using the @backstage-community/plugin-catalog-backend-module-scaffolder-relation-processor module, an extension to the catalog-backend plugin. When enabled, this module automatically notifies component owners whenever the Software Template used to generate their components is updated to a new version.

This functionality uses the spec.scaffoldedFrom field in catalog entities. This field links Software Templates to the entities they have scaffolded. By tracking this relationship, the module helps teams stay informed and take advantage of the latest improvements or fixes.

The plugin-catalog-backend-module-scaffolder-relation-processor module is disabled by default.

Prerequisites

  • You have installed and configured the RHDH notification plugins:

    • backend: @backstage/plugin-notifications-backend
    • frontend: @backstage/plugin-notifications

Procedure

  1. Open your RHDH app-config.yaml file.
  2. Add the following conifugration to the scaffolder section to enable Software Template update notifications
  3. Optional: To customize the notification title and description, add the message block:

    scaffolder:
      notifications:
        templateUpdate:
          enabled: true
          message:
            title: 'Custom title for $ENTITY_DISPLAY_NAME'
            description: 'Custom description'
    Copy to Clipboard Toggle word wrap

    where:

    enabled
    Set to true to enable the notification. Default value is false.
    message:title
    Enter the notification title.
    message:description
    Enter the notification description.
Note

The message:title and message:description fields support the $ENTITY_DISPLAY_NAME variable. The system replaces this variable with the title (or the name, if the title is missing) of the scaffolded entity.

Verification

  1. Log in to your Red Hat Developer Hub instance.
  2. In the left navigation menu, verify that the Notifications item appears.
  3. Update the version of a Software Template and verify that the owner of a component scaffolded from that template receives a notification.

4.3. Tracking Component origin and Software Template version

Platform engineers use custom actions within the Software Template scaffolding process to establish and track the dependency link between a generated entity (Component or Resource) and its source template. This relationship is called scaffolding provenance.

Platform administrators use custom actions such as catalog:scaffolded-from and catalog:template:version in the Scaffolder backend module to track the template version and the corresponding entity version, which simplifies lifecycle management.

As a platform engineer, you must modify the Software Template YAML definition to ensure the required provenance information is added during the scaffolding process.

Prerequisites

  • You have administrator rights to Red Hat Developer Hub.

Procedure

  1. Locate the Software Template object YAML file where you want to add the provenance information and add a step that uses the catalog:scaffolded-from action. This action links the resulting catalog entity back to the source template.
  2. Optional: To track the template version (for example, v1.0 versus v1.5), include the catalog:template:version action in the steps section. The following code block is an example to adding versioning action to the steps section:

    steps:
      - id: create-provenance-annotation
        name: Append the entityRef of this template to the entityRef
        action: catalog:scaffolded-from
      - id: create-version-annotation
        name: Create Template Version Annotation
        action: catalog:template:version
        input:
          templateVersion: ${{ parameters.version }}
      - ... other steps ...
    Copy to Clipboard Toggle word wrap

    where:

    steps:input:templateVersion

    Reads the version parameter

    Note

    The catalog:template:version action reads a version parameter defined in the template and applies it as an annotation to the resulting catalog entity.

  3. In your Red Hat Developer Hub app-config.yaml file, configure the catalog.locations section to point to the Software Template that you want to add. You might need to add Template to the global catalog.rules.allow list or add a granular rule to the location to allow for Software Templates ingestion, as shown in the following example:

    # ...
    catalog:
      locations:
        - type: url
          target: https://<repository_url>/example-template.yaml
          rules:
            - allow: [Template]
    # ...
    Copy to Clipboard Toggle word wrap

    where:

    catalog.locations.type
    Enter the url type if you are importing templates from a repository, such as GitHub or GitLab.
    catalog.locations.target
    Enter the URL for the template.
    catalog.locations.rules.allow
    Enter the Template rule to allow new Software Templates to be added to the catalog.

Verification

After creating a component with the updated template, verify the provenance annotations in the resulting Catalog Entity YAML.

  1. In the Red Hat Developer Hub navigation menu, go to Catalog and locate the newly created catalog component.
  2. To view the underlying data that links the entity to the template, select the INSPECT ENTITY option.
  3. To verify provenance annotations, complete the following steps:

    1. Select the YAML Raw or JSON Raw view and verify the presence of the data item for the scaffoldedFrom link.
    2. Optional: If versioning was included, verify the presence of the backstage.io/template-version annotation.

      Note

      If you publish the catalog component to an external repository (such as Git), the component file in that repository must also contain the backstage.io/template-version annotation.

4.3.2. Viewing Software Template dependencies

As a developer, you can track which entities were created from a specific Software Template. When a platform engineer configures provenance on a template, you can quickly identify the complete dependency and impact map of that template by viewing all linked components and resources in the Catalog.

Procedure

To view all components created from a specific template, complete the following steps:

  1. In the Red Hat Developer Hub navigation menu, click Catalog, use the filters to find and select the Software Template you wish to inspect.
  2. In the Software Template detail page, click the Dependencies tab. This view lists all catalog entities such as components, resources, and systems that reference this template, including any version information if configured.

4.4. Automated Software Template lifecycle management

When Software Templates receive security updates or configuration changes, you can apply those updates to all downstream repositories automatically so that your applications remain compliant without manual file comparisons.

Automated template lifecycle management maintains consistency by monitoring your source templates. When a template version changes, the scaffolder-relation-processor plugin identifies all entities provisioned from that template and creates a pull request (PR) or merge request (MR) containing the necessary file updates, additions, or deletions.

4.4.1. Enabling automated template updates

To automate the synchronization of changes from Software Templates to your repositories, you must configure the plugin in your backend settings and ensure that your entities contain the required metadata.

Prerequisites

  • You have administrator access to the Red Hat Developer Hub configuration.
  • You have configured GitHub or GitLab integrations in your RHDH app-config.yaml file.
  • Your scaffolded entities include the spec.scaffoldedFrom field referencing the source template.
  • Your entities include the backstage.io/managed-by-location annotation pointing to a valid GitHub or GitLab URL.

Procedure

  1. Enable the template sync and notification plugins in your RHDH dynamic-plugins.yaml file:

    plugins:
    # Enables the core template synchronization logic
      - package: './dynamic-plugins/dist/backstage-community-plugin-scaffolder-backend-module-scaffolder-relation-processor'
        disabled: false
    # Required only if you want to receive notifications for new pull requests
      - package: './dynamic-plugins/dist/backstage-plugin-notifications'
        disabled: false
    Copy to Clipboard Toggle word wrap
  2. Open your RHDH app-config.yaml file.
  3. Configure the pull request (PR) feature by adding the following configuration:

    scaffolder:
      pullRequests:
        templateUpdate:
          enabled: true
    Copy to Clipboard Toggle word wrap
  4. Optional: Enable notifications to alert entity owners when a PR is created:

    scaffolder:
      notifications:
        templateUpdate:
          enabled: true
    Copy to Clipboard Toggle word wrap
  5. Restart the Red Hat Developer Hub instance to apply the changes.

Verification

  1. Update the version of a source template in its repository.
  2. Navigate to a repository scaffolded from that template.
  3. Confirm that a new pull request named [component-name]/template-upgrade-v[version] exists.

4.4.2. Template sync considerations and limitations

Review the following details to troubleshoot or refine the synchronization process.

Reviewer assignment

The plugin automatically assigns a reviewer if the entity owner is a User entity with a defined VCS login.

  • GitHub: Requires the github.com/user-login annotation.
  • GitLab: Requires the gitlab.com/user-login annotation. If the owner is a Group, the plugin creates the PR without an assigned reviewer.

Variable resolution limitations

The synchronization engine uses regex matching to resolve template variables like ${{ values.name }}. You must manually review PRs because:

  • Variables that do not match keys in the scaffolded repository remain in raw template syntax.
  • Conditional Jinja2 blocks ({% if %}) are stripped, which might cause unexpected formatting.
  • Complex nested structures might not resolve correctly.

Error handling

If a PR fails to create due to credential issues or network errors, the plugin:

  • Logs the error in the backend.
  • Sends a failure notification to the entity owner (if notifications are enabled).
  • Skips the sync if no file differences are detected between the template and the repository.

4.4.3. Template synchronization and notification outcomes

You can enable pull requests and notifications independently. The following table describes the behavior for each configuration combination:

Expand
PR CreationNotificationsOutcome

Disabled

Disabled

No action occurs when a template updates.

Disabled

Enabled

The plugin sends a notification to the entity owner with a link to the catalog.

Enabled

Disabled

The plugin creates a PR but sends no notification.

Enabled

Enabled

The plugin creates a PR and sends a notification to the owner with a link to the PR.

Note

If PR creation fails, the plugin sends a notification containing error details instead of the custom message.

Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red Hat
Nach oben