You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: assemblies/assembly-tracking-component-origin-and-software-template-version.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@
5
5
6
6
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.
7
7
8
-
Platform administrators use the existing custom actions `catalog:scaffolded-from` and `catalog:template:version` in the scaffolder backend module. These actions track the template version and the corresponding entity version, which simplifies lifecycle management.
8
+
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.
Copy file name to clipboardExpand all lines: modules/tracking-component-origin-and-software-template-version/proc-configuring-provenance-and-software-template-versioning.adoc
+12-8Lines changed: 12 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,11 +12,10 @@ As a platform engineer, you must modify the Software Template YAML definition to
12
12
.Procedure
13
13
14
14
. 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.
15
-
. Optional: To track the template version (for example, v1.0 versus v1.5), include the `catalog:template:version` action in the `steps` section.
15
+
. 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:
16
16
+
17
17
[source,yaml]
18
18
----
19
-
# Example: Adding the versioning action to the steps section
20
19
steps:
21
20
- id: create-provenance-annotation
22
21
name: Append the entityRef of this template to the entityRef
@@ -25,16 +24,20 @@ steps:
25
24
name: Create Template Version Annotation
26
25
action: catalog:template:version
27
26
input:
28
-
templateVersion: ${{ parameters.version }} # Reads the version parameter
27
+
templateVersion: ${{ parameters.version }}
29
28
- ... other steps ...
30
29
----
31
30
+
31
+
where:
32
+
33
+
`steps:input:templateVersion`:: Reads the version parameter
34
+
+
32
35
[NOTE]
33
36
====
34
-
This action reads a version parameter defined in the template and applies it as an annotation to the resulting catalog entity.
37
+
The `catalog:template:version` action reads a version parameter defined in the template and applies it as an annotation to the resulting catalog entity.
35
38
====
36
39
37
-
. In your `{product} {my-app-config-file}` 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::
40
+
. In your {product} `{my-app-config-file}` 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:
38
41
+
39
42
[source,yaml]
40
43
----
@@ -47,11 +50,12 @@ catalog:
47
50
- allow: [Template]
48
51
# ...
49
52
----
53
+
+
50
54
where:
51
55
52
-
`catalog.locations.type`:: If you are importing templates from a repository, such as GitHub or GitLab, use the `url` type.
53
-
`catalog.locations.target`:: Specify the URL for the template.
54
-
`catalog.locations.rules.allow`:: To allow new Software Templates to be added to the catalog, you must add a `Template` rule.
56
+
`catalog.locations.type`:: Enter the `url` type if you are importing templates from a repository, such as GitHub or GitLab.
57
+
`catalog.locations.target`:: Enter the URL for the template.
58
+
`catalog.locations.rules.allow`:: Enter the `Template` rule to allow new Software Templates to be added to the catalog.
Copy file name to clipboardExpand all lines: modules/tracking-component-origin-and-software-template-version/proc-viewing-software-template-dependencies.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,4 +9,4 @@ As a developer, you can track which entities were created from a specific Softwa
9
9
To view all components created from a specific template, complete the following steps:
10
10
11
11
. In the {product} navigation menu, click *Catalog*, use the filters to find and select the Software Template you wish to inspect.
12
-
. In the Software Template detail page, click the *Dependencies* tab. This view lists all catalog entities (components, resources, systems, etc.) that reference this template, including any version information if configured.
12
+
. 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.
0 commit comments