[WIP] SECURESIGN-4640 Add rhtas-versions.properties file

[jkopriva]

Assisted-by: Cursor

[github-actions]

Configuration Diff

3 document(s) impacted:

+ 1 added
- 0 removed
! 2 modified

Diff

@@ metadata.labels.build.rhtas.com/ec @@
# projctl.konflux.dev/v1beta1/ProjectDevelopmentStreamTemplate/rhtas-tenant/model-validation-operator-template
! ± value change
- registry-rhtas-operator
+ registry-rhtas-operator-group-only

@@ spec.resources @@
# projctl.konflux.dev/v1beta1/ProjectDevelopmentStreamTemplate/rhtas-tenant/model-validation-operator-template
! - one list entry removed:
- - apiVersion: appstudio.redhat.com/v1beta2
-   kind: IntegrationTestScenario
-   metadata:
-     name: {{.application}}{{.nameSuffix}}-enterprise-contract
-     annotations:
-       test.appstudio.openshift.io/kind: enterprise-contract
-   spec:
-     application: {{.application}}{{.nameSuffix}}
-     contexts:
-     - name: component_{{.operator}}{{.nameSuffix}}
-       description: "execute the integration test when component {{.operator}}{{.nameSuffix}} updates"
-     params:
-     - name: POLICY_CONFIGURATION
-       value: rhtap-releng-tenant/registry-rhtas
-     - name: SINGLE_COMPONENT
-       value: "true"
-     resolverRef:
-       params:
-       - name: url
-         value: "https://github.com/redhat-appstudio/build-definitions"
-       - name: revision
-         value: main
-       - name: pathInRepo
-         value: pipelines/enterprise-contract.yaml
-       resolver: git
-       resourceKind: pipeline

@@ (root level) @@
# v1/ConfigMap/rhtas-tenant/rhtas-repo-branch-versions
! + one document added:
+   ---
+   apiVersion: v1
+   data:
+     artifact-signer-ansible: 1.5.0-dev
+     artifact-signer-ansible__main: 1.5.0
+     artifact-signer-ansible__release-1.3: 1.3.6
+     artifact-signer-ansible__release-1.4: 1.4.2
+     certificate-transparency-go: 1.5.0-dev
+     certificate-transparency-go__main: 1.5.0
+     certificate-transparency-go__release-1.3: 1.3.6
+     certificate-transparency-go__release-1.4: 1.4.2
+     cosign: 1.5.0-dev
+     cosign__main: 1.5.0
+     cosign__release-1.3: 1.3.6
+     cosign__release-1.4: 1.4.2
+     fulcio: 1.5.0-dev
+     fulcio__main: 1.5.0
+     fulcio__release-1.3: 1.3.6
+     fulcio__release-1.4: 1.4.2
+     gitsign: 1.5.0-dev
+     gitsign__main: 1.5.0
+     gitsign__release-1.3: 1.3.6
+     gitsign__release-1.4: 1.4.2
+     model-transparency: 1.5.0-dev
+     model-transparency-go: 1.5.0-dev
+     model-transparency-go__main: 1.5.0
+     model-transparency-go__release-1.3: 1.3.6
+     model-transparency-go__release-1.4: 1.4.2
+     model-transparency__main: 0.1.0
+     model-validation-operator: 1.5.0-dev
+     model-validation-operator__main: 0.1.0
+     policy-controller: 1.5.0-dev
+     policy-controller-operator: 1.5.0-dev
+     policy-controller-operator__main: 1.5.0
+     policy-controller-operator__release-1.0: 1.4.2
+     policy-controller__main: 1.5.0
+     policy-controller__release-1.0: 1.4.2
+     rekor: 1.5.0-dev
+     rekor-monitor: 1.5.0-dev
+     rekor-monitor__main: 1.5.0-dev
+     rekor-monitor__release-1.3: 1.3.6
+     rekor-monitor__release-1.4: 1.4.2
+     rekor-search-ui: 1.5.0-dev
+     rekor-search-ui__main: 1.5.0
+     rekor-search-ui__release-1.3: 1.3.6
+     rekor-search-ui__release-1.4: 1.4.2
+     rekor__main: 1.5.0
+     rekor__release-1.3: 1.3.6
+     rekor__release-1.4: 1.4.2
+     rhtas-console: 1.5.0-dev
+     rhtas-console-ui: 1.5.0-dev
+     rhtas-console-ui__main: 1.5.0
+     rhtas-console-ui__release-1.3: 1.3.6
+     rhtas-console-ui__release-1.4: 1.4.2
+     rhtas-console__main: 1.5.0
+     rhtas-console__release-1.3: 1.3.6
+     rhtas-console__release-1.4: 1.4.2
+     secure-sign-operator: 1.5.0-dev
+     secure-sign-operator__main: 1.5.0
+     secure-sign-operator__release-1.3: 1.3.6
+     secure-sign-operator__release-1.4: 1.4.2
+     segment-backup-job: 1.5.0-dev
+     segment-backup-job__main: 1.5.0-dev
+     segment-backup-job__release-1.3: 1.3.6
+     segment-backup-job__release-1.4: 1.4.2
+     timestamp-authority: 1.5.0-dev
+     timestamp-authority__main: 1.5.0
+     timestamp-authority__release-1.3: 1.3.6
+     timestamp-authority__release-1.4: 1.4.2
+     tough: 1.5.0-dev
+     tough__develop: 1.5.0
+     tough__release-1.3: 1.3.6
+     tough__release-1.4: 1.4.2
+     trillian: 1.5.0-dev
+     trillian__main: 1.5.0
+     trillian__release-1.3: 1.3.6
+     trillian__release-1.4: 1.4.2
+     tuf-server: 1.5.0-dev
+     tuf-server__main: 1.5.0
+     tuf-server__release-1.3: 1.3.6
+     tuf-server__release-1.4: 1.4.2
+   kind: ConfigMap
+   metadata:
+     name: rhtas-repo-branch-versions
+     namespace: rhtas-tenant

---

_{📦 Artifacts: base-output.yaml, head-output.yaml, dyff-output.txt}

[qodo-for-securesign]

PR Summary by Qodo

Centralize repo/branch release versions via ConfigMap for Tekton builds

✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 40+ Minutes

AI Description

• Add a central repo+branch → version mapping ConfigMap generated from a properties file
• Update build pipelines to resolve image version via a shared Tekton task before labeling
• Adjust PR pipeline triggers and EC template to support the new task and group-only EC runs

Diagram

graph TD
  A["Pipelines-as-Code PR" ] --> B["Tekton build pipeline" ] --> C("get-version-from-configmap") --> D[("ConfigMap: rhtas-repo-branch-versions")]
  C --> E["derive-product-version" ] --> F["generate labels / build" ]
  G["konflux-configs rhtas-versions.properties" ] --> H["Kustomize configMapGenerator" ] --> D

  subgraph Legend
    direction LR
    _pipe["Pipeline"] ~~~ _task("Task") ~~~ _cm[("ConfigMap")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep per-repo Tekton params for release-version

• ➕ No cluster ConfigMap dependency during builds
• ➕ Version changes are localized to each component repo
• ➖ Coordinated release bumps require many PRs across repos
• ➖ Higher risk of drift/inconsistency across branches

2. Derive version from git tags/releases instead of a ConfigMap

• ➕ Source-of-truth stays with the code repo history
• ➕ Avoids maintaining a separate mapping file
• ➖ Harder to support per-branch override/fallback semantics
• ➖ Requires consistent tagging discipline and additional SCM/API logic in pipelines

3. Use a dedicated version service/registry endpoint

• ➕ Centralized updates with richer validation and audit trails
• ➕ Potentially more scalable than ConfigMap for many mappings
• ➖ Adds a new runtime dependency and operational surface area
• ➖ Overkill for static semver mapping needs

Recommendation: Proceed with the ConfigMap + properties-file approach: it keeps version management centralized and PR-driven while staying simple and GitOps-friendly. The main tradeoff is introducing a cluster lookup dependency (oc get configmap) during pipeline execution; ensure the ConfigMap is reliably deployed in target namespaces and consider documenting required RBAC if not already guaranteed by the pipeline SA.

Files changed (15) +442 / -22

Enhancement (5) +211 / -19

bundle-build-oci-ta.yamlResolve release-version from ConfigMap before deriving product version +24/-3

Resolve release-version from ConfigMap before deriving product version

• Adds the get-version-from-configmap task and wires its release-version result into derive-product-version. Also replaces hard-pinned git resolver revisions with $(params.revision) for better pipeline testability and consistency.

pipelines/bundle-build-oci-ta.yaml

docker-build-multi-platform-oci-ta.yamlAdd ConfigMap-driven version lookup and bump Go toolset digest +27/-6

Add ConfigMap-driven version lookup and bump Go toolset digest

• Introduces get-version-from-configmap and feeds its result into derive-product-version with explicit runAfter ordering. Updates the default Go base image digest and swaps several taskRef git revisions to $(params.revision).

pipelines/docker-build-multi-platform-oci-ta.yaml

docker-build-oci-ta.yamlAdd ConfigMap-driven version lookup and bump Go toolset digest +26/-5

Add ConfigMap-driven version lookup and bump Go toolset digest

• Adds get-version-from-configmap ahead of derive-product-version and replaces pinned git resolver revisions with $(params.revision). Updates the default Go toolset digest used for unit tests.

pipelines/docker-build-oci-ta.yaml

docker-build.yamlAdd ConfigMap-driven version lookup and bump Go toolset digest +26/-5

Add ConfigMap-driven version lookup and bump Go toolset digest

• Adds get-version-from-configmap and uses its resolved release-version for downstream version derivation and labeling. Also updates the Go toolset digest and replaces pinned resolver revisions with $(params.revision).

pipelines/docker-build.yaml

get-version-from-configmap.yamlAdd Tekton task to resolve release version from ConfigMap +108/-0

Add Tekton task to resolve release version from ConfigMap

• Introduces a new Task that determines repo name from git-url and performs hierarchical lookup (<repo>__<branch> → <repo> → default) in the rhtas-repo-branch-versions ConfigMap. Writes both the resolved release-version and the successful lookup-key as task results, with branch defaulting from the PipelineRun target_branch annotation when not provided.

tasks/get-version-from-configmap.yaml

Documentation (1) +42 / -0

README.mdDocument centralized release version mappings +42/-0

Document centralized release version mappings

• Adds documentation describing the rhtas-versions.properties source-of-truth, key formats (<repo>__<branch> and <repo> fallback), and how to bump and verify versions via the get-version-from-configmap task logs and image labels.

konflux-configs/README.md

Other (9) +189 / -3

docker-build-multi-platform-oci-ta-pull-request.yamlTrigger PR pipeline when version-lookup task changes +1/-0

Trigger PR pipeline when version-lookup task changes

• Extends the Pipelines-as-Code CEL pathChanged filter to include the new get-version-from-configmap task file so PR validation runs when the task is modified.

.tekton/docker-build-multi-platform-oci-ta-pull-request.yaml

docker-build-oci-ta-pull-request.yamlInclude version-lookup task in PR trigger filter +1/-1

Include version-lookup task in PR trigger filter

• Updates the PR trigger expression to rerun pipelines when tasks/get-version-from-configmap.yaml changes, alongside existing unit test task triggers.

.tekton/docker-build-oci-ta-pull-request.yaml

docker-build-pull-request.yamlInclude version-lookup task in PR trigger filter +1/-0

Include version-lookup task in PR trigger filter

• Adds tasks/get-version-from-configmap.yaml to the pathChanged set so standard docker-build PR pipeline runs when the task changes.

.tekton/docker-build-pull-request.yaml

kustomization.yamlGenerate version-mapping ConfigMap from properties file +6/-0

Generate version-mapping ConfigMap from properties file

• Adds a new configMapGenerator entry (rhtas-repo-branch-versions) that sources env-style data from rhtas-versions.properties.

konflux-configs/base/config/kustomization.yaml

rhtas-versions.propertiesAdd repo/branch → release version mapping file +144/-0

Add repo/branch → release version mapping file

• Introduces a properties file defining version mappings for multiple components across branches, plus repo-only fallback keys used when a branch-specific entry is missing.

konflux-configs/base/config/rhtas-versions.properties

kustomization.yamlAdd EC patch for group-only enterprise contract runs +7/-0

Add EC patch for group-only enterprise contract runs

• Adds a new patch target for templates labeled registry-rhtas-operator-group-only to run enterprise contract validation against group snapshots for operator monorepos.

konflux-configs/base/project/base/ec/kustomization.yaml

registry-rhtas-operator-group-only.yamlDefine IntegrationTestScenario for group snapshot EC +27/-0

Define IntegrationTestScenario for group snapshot EC

• Creates a JSON6902 patch that adds an IntegrationTestScenario configured to run enterprise contract with a 'group' snapshot context and the registry-rhtas policy configuration.

konflux-configs/base/project/base/ec/patch/registry-rhtas-operator-group-only.yaml

template.yamlSwitch model-validation-operator EC label to group-only +1/-1

Switch model-validation-operator EC label to group-only

• Updates the template label so the model-validation-operator uses the new group-only EC scenario selection instead of the prior registry-rhtas-operator label.

konflux-configs/base/project/overlay/model-validation-operator/template.yaml

fbc-builder.yamlUnpin derive-product-version task revision +1/-1

Unpin derive-product-version task revision

• Switches the derive-product-version taskRef revision to use $(params.revision) instead of a fixed commit, aligning with other pipelines' revision handling.

pipelines/fbc-builder.yaml

[qodo-for-securesign]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Unquoted JSONPath key ✓ Resolved 🐞 Bug ≡ Correctness

Description

get-version-from-configmap queries ConfigMap data using jsonpath="{.data.${LOOKUP_KEY}}", which
breaks when ${LOOKUP_KEY} contains a dot (e.g., fulcio__release-1.4), so branch-specific
mappings will not be read and the task will fall back to repo/default instead.

Code

tasks/get-version-from-configmap.yaml[R78-83]

+        LOOKUP_KEY="${REPO_NAME}__${BRANCH}"
+        echo "Looking up key: ${LOOKUP_KEY}"
+
+        VERSION=$(oc get configmap "${CM_NAME}" -n "${CM_NAMESPACE}" \
+          -o jsonpath="{.data.${LOOKUP_KEY}}" 2>/dev/null || echo "")
+

Relevance

⭐⭐⭐ High

Clear correctness bug: JSONPath breaks for keys containing dots; deterministic quoting fix.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The task builds a lookup key from repo+branch and uses it directly as a JSONPath field selector; the
mapping file defines keys containing dots in the branch segment (e.g., release-1.4 /
release-1.0), which cannot be addressed via {.data.<key>} syntax.

tasks/get-version-from-configmap.yaml[78-83]
konflux-configs/base/config/rhtas-versions.properties[11-14]
konflux-configs/base/config/rhtas-versions.properties[111-117]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The task uses an unquoted JSONPath field selector (`{.data.${LOOKUP_KEY}}`). Keys like `fulcio__release-1.4` include a `.` and cannot be accessed via dot-notation selectors, causing lookups to miss.

### Issue Context
The version mapping file explicitly defines keys with dots in the branch portion (e.g., `release-1.4`, `release-1.0`).

### Fix Focus Areas
- tasks/get-version-from-configmap.yaml[78-83]

### Implementation notes
Update the lookup to use a safe key access method, e.g.:
- Fetch JSON and index with jq:
 - `VERSION=$(oc get configmap ... -o json | jq -r --arg k "$LOOKUP_KEY" '.data[$k] // empty')`
- Or use go-template `index`:
 - `oc get configmap ... -o go-template='{{ index .data "'"$LOOKUP_KEY"'" }}'`
Apply the same fix for the repo-only lookup.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. ConfigMap errors suppressed 🐞 Bug ◔ Observability

Description

The task suppresses oc errors (2>/dev/null and || echo ""), so RBAC issues or a missing
ConfigMap are indistinguishable from a missing key and will silently fall back to default-version,
producing incorrect version labels without a clear failure signal.

Code

tasks/get-version-from-configmap.yaml[R81-83]

+        VERSION=$(oc get configmap "${CM_NAME}" -n "${CM_NAMESPACE}" \
+          -o jsonpath="{.data.${LOOKUP_KEY}}" 2>/dev/null || echo "")
+

Relevance

⭐⭐ Medium

Some precedent for failing fast, but silent fallback might be intentional for optional ConfigMap.

PR-#84

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Both lookups discard stderr and convert any non-zero oc exit into an empty VERSION, and the task
then unconditionally falls back when VERSION is empty, masking ConfigMap/RBAC problems.

tasks/get-version-from-configmap.yaml[81-83]
tasks/get-version-from-configmap.yaml[95-108]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`oc get configmap ...` failures are silenced and converted into an empty string, so operational problems (missing CM / forbidden) look like a missing mapping and the task quietly emits the fallback version.

### Issue Context
This can cause builds to succeed with incorrect metadata, and logs will misleadingly say "No ConfigMap entry found".

### Fix Focus Areas
- tasks/get-version-from-configmap.yaml[81-83]
- tasks/get-version-from-configmap.yaml[95-108]

### Implementation notes
- Remove `2>/dev/null` and the `|| echo ""` masking, or explicitly detect failures:
 - First validate the ConfigMap is readable: `oc get configmap "$CM_NAME" -n "$CM_NAMESPACE" >/dev/null` and exit non-zero with an actionable error if it fails.
 - Only treat "key not present" as a fallback condition.
- If fallback-on-error is required, log the actual `oc` error to stderr and set `lookup-key` to something like `error:<reason>` so it’s detectable.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[tommyd450]

lets set this back to main

[tommyd450]

Cannot access pipeline directly like this.