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 Link kopierenLink in die Zwischenablage kopiert!
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
Backstageormy-rhdh-app-configfile:-
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:
Make sure the required plugins are enabled in your RHDH
my-rhdh-app-configfile or the Backstage custom resource (CR):Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Modify the Software Template that you want to update.
Complete one or both of the following tasks:
-
Include the annotation in your template: Add the
backstage.io/template-versionannotation 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.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Include the annotation in your template: Add the
Verification
- 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).
Check the component in the Catalog UI.
- On the Catalog page, locate the newly created catalog component.
-
Verify that the
backstage.io/template-versionannotation 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.
Only if you have published the catalog component: Check the component file in the repository.
- If VIEW SOURCE is present in your UI: Click VIEW SOURCE to open the stored component file in the repository.
-
Locate the file manually and verify that the
backstage.io/template-versionannotation is present.
4.2. Enabling Software Template version update notifications in Red Hat Developer Hub Link kopierenLink in die Zwischenablage kopiert!
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
-
backend:
Procedure
-
Open your RHDH
app-config.yamlfile. -
Add the following conifugration to the
scaffoldersection to enable Software Template update notifications Optional: To customize the notification title and description, add the
messageblock:Copy to Clipboard Copied! Toggle word wrap Toggle overflow where:
enabled-
Set to
trueto enable the notification. Default value isfalse. message:title- Enter the notification title.
message:description- Enter the notification description.
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
-
Log in to your
Red Hat Developer Hubinstance. - In the left navigation menu, verify that the Notifications item appears.
- 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 Link kopierenLink in die Zwischenablage kopiert!
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.
4.3.1. Configuring provenance and Software Template versioning Red Hat Developer Hub Link kopierenLink in die Zwischenablage kopiert!
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
-
Locate the Software Template object YAML file where you want to add the provenance information and add a step that uses the
catalog:scaffolded-fromaction. This action links the resulting catalog entity back to the source template. Optional: To track the template version (for example, v1.0 versus v1.5), include the
catalog:template:versionaction in thestepssection. The following code block is an example to adding versioning action to thestepssection:Copy to Clipboard Copied! Toggle word wrap Toggle overflow where:
steps:input:templateVersionReads the version parameter
NoteThe
catalog:template:versionaction reads a version parameter defined in the template and applies it as an annotation to the resulting catalog entity.
In your Red Hat Developer Hub
app-config.yamlfile, configure thecatalog.locationssection to point to the Software Template that you want to add. You might need to addTemplateto the globalcatalog.rules.allowlist or add a granular rule to the location to allow for Software Templates ingestion, as shown in the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow where:
catalog.locations.type-
Enter the
urltype 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
Templaterule 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.
- In the Red Hat Developer Hub navigation menu, go to Catalog and locate the newly created catalog component.
- To view the underlying data that links the entity to the template, select the INSPECT ENTITY option.
To verify provenance annotations, complete the following steps:
-
Select the YAML Raw or JSON Raw view and verify the presence of the data item for the
scaffoldedFromlink. Optional: If versioning was included, verify the presence of the
backstage.io/template-versionannotation.NoteIf 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-versionannotation.
-
Select the YAML Raw or JSON Raw view and verify the presence of the data item for the
4.3.2. Viewing Software Template dependencies Link kopierenLink in die Zwischenablage kopiert!
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:
- In the Red Hat Developer Hub navigation menu, click Catalog, use the filters to find and select the Software Template you wish to inspect.
- 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 Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
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.yamlfile. -
Your scaffolded entities include the
spec.scaffoldedFromfield referencing the source template. -
Your entities include the
backstage.io/managed-by-locationannotation pointing to a valid GitHub or GitLab URL.
Procedure
Enable the template sync and notification plugins in your
RHDH dynamic-plugins.yamlfile:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open your
RHDH app-config.yamlfile. Configure the pull request (PR) feature by adding the following configuration:
scaffolder: pullRequests: templateUpdate: enabled: truescaffolder: pullRequests: templateUpdate: enabled: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: Enable notifications to alert entity owners when a PR is created:
scaffolder: notifications: templateUpdate: enabled: truescaffolder: notifications: templateUpdate: enabled: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Restart the Red Hat Developer Hub instance to apply the changes.
Verification
- Update the version of a source template in its repository.
- Navigate to a repository scaffolded from that template.
-
Confirm that a new pull request named
[component-name]/template-upgrade-v[version]exists.
4.4.2. Template sync considerations and limitations Link kopierenLink in die Zwischenablage kopiert!
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-loginannotation. -
GitLab: Requires the
gitlab.com/user-loginannotation. 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 Link kopierenLink in die Zwischenablage kopiert!
You can enable pull requests and notifications independently. The following table describes the behavior for each configuration combination:
| PR Creation | Notifications | Outcome |
|---|---|---|
| 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. |
If PR creation fails, the plugin sends a notification containing error details instead of the custom message.