feat(RELEASE-2460): add disk-image support to push-artifacts-to-cdn by swickersh · Pull Request #2334 · konflux-ci/release-service-catalog

swickersh · 2026-06-27T03:41:52Z

- push-artifacts-to-cdn pipeline: update release-service-utils
  image from utils PR 833
- create-advisory-task: add disk-image to contentType allowlist,
  routing it to .content.artifacts
- create-advisory: fix PURL generation for disk images - generate
  one entry per staged file instead of per os+arch advisory entry
- create-advisory: fix dedup for disk-image artifacts - replace
  entries rather than map-merge to retain multiple files per
  component

Will be merged with
http://github.com/konflux-ci/release-service-utils/pull/833

Assisted-by: Cursor AI

Checklist before requesting a review

I have marked as draft or added do not merge label if there's a dependency PR
- If you want reviews on your draft PR, you can add reviewers or add the release-service-maintainers handle if you are unsure who to tag
My commit message includes Signed-off-by: My name <email>
I read CONTRIBUTING.MD and commit formatting
I have run the README.md generator script in .github/scripts/readme_generator.sh and verified the results using .github/scripts/check_readme.sh
If an AI agent was used, I marked that via a commit footer like Assisted-By: Cursor

qodo-app-for-konflux-ci · 2026-06-30T20:57:49Z

PR Reviewer Guide 🔍

(Review updated until commit `9e2cf39`)

Warning

/review is deprecated. Use /agentic_review instead (removal date not yet scheduled).

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪
🧪 PR contains tests
🔒 Security concerns Supply chain risk: The PR introduces a temporary execution image (`quay.io/redhat-user-workloads/.../release-service-utils-standalone@sha256:...`) for a task step. Even though it is digest-pinned, hosting under a non-standard namespace can weaken provenance guarantees compared to the official `quay.io/konflux-ci/release-service-utils` releases. Ensure this image is built by the expected pipeline, signed/attested as required, and replaced promptly once PR #833 is released.
⚡ Recommended focus areas for review Robustness The new disk-image PURL generation derives architecture from filename substrings and hardcodes OS to linux. This can misclassify artifacts when filenames don’t include those substrings or when snapshot staged file metadata already contains arch/os that should be preferred. Also validate behavior when staged.files is empty/missing for a disk-image component (it currently silently produces no updated entries for that component). if [ "$content_type" = "disk-image" ]; then # For disk-images, generate one advisory entry per file in staged.files[]. # Multiple files can share the same os+arch (e.g. ISO + QCOW2 both linux/amd64), # so iterating over advisory entries (one per os+arch) would produce malformed PURLs. # Instead, use the first advisory entry as a metadata template and expand it per file. TEMPLATE_ENTRY=$(echo "$MATCHING_ENTRIES" \| head -1) # When a component has both contentGateway (Developer Portal) and staged (Customer # Portal/CDN), CGW is used as the canonical download_url in the PURL. If only # staged is present, the CDN URL is used instead. HAS_CGW=$(jq -r 'if ((.contentGateway // {}) \| length) > 0 then "true" else "false" end' \ <<< "$component") if [ "$HAS_CGW" = "true" ]; then DOWNLOAD_URL="$CGW_BASE_URL" else DOWNLOAD_URL="$CDN_BASE_URL" fi while IFS= read -r staged_file; do FILENAME=$(jq -r '.filename' <<< "$staged_file") FILENAME_BASENAME=$(basename "$FILENAME") # Derive arch from filename (same logic as populate-release-notes) FILE_ARCH="unknown" if [[ "$FILENAME_BASENAME" == "aarch64" ]]; then FILE_ARCH="aarch64" elif [[ "$FILENAME_BASENAME" == "x86_64" ]]; then FILE_ARCH="x86_64" fi FILE_OS="linux" # Default for disk images CHECKSUM=$(jq -r --arg component "$COMPONENT_NAME" --arg filename "$FILENAME_BASENAME" \ '.[] \| select(.component == $component) \| .files[$filename] // empty' \ <<< "$CHECKSUM_MAP_JSON") if [ -z "$CHECKSUM" ]; then echo "Warning: No checksum found for $COMPONENT_NAME/$FILENAME_BASENAME in manifest" >&2 fi PURL="pkg:generic/$COMPONENT_NAME@$VERSION_NAME" QUERY_PARAMS=() # Add filename first - this uniquely identifies the file if [ -n "$FILENAME_BASENAME" ]; then QUERY_PARAMS+=("filename=$FILENAME_BASENAME") fi if [ -n "$CHECKSUM" ]; then QUERY_PARAMS+=("checksum=$CHECKSUM") fi if [ -n "$DOWNLOAD_URL" ]; then QUERY_PARAMS+=("download_url=$DOWNLOAD_URL") fi if [ "${#QUERY_PARAMS[@]}" -gt 0 ]; then PURL="${PURL}?$(IFS=\&; echo "${QUERY_PARAMS[*]}")" fi UPDATED_ENTRY=$(jq -c \ --arg purl "$PURL" --arg arch "$FILE_ARCH" --arg os "$FILE_OS" \ '.purl = $purl \| .architecture = $arch \| .os = $os' <<< "$TEMPLATE_ENTRY") UPDATED_ENTRIES+=("$UPDATED_ENTRY") done <<< "$(jq -c --arg name "$COMPONENT_NAME" '.[$name][]?' <<< "$SNAPSHOT_STAGED")" else
📚 Focus areas based on broader codebase context Image Source The task step image was switched from the standard `quay.io/konflux-ci/release-service-utils@sha256:...` to a tenant-scoped `quay.io/redhat-user-workloads/...` digest. Validate that this alternative registry/image is allowed in all target clusters/environments and that it won’t break reproducibility or access controls in the managed pipeline. Ensure a concrete follow-up to revert to the canonical `release-service-utils` image digest once the dependent change is published. (Ref 1) # TODO(RELEASE-2460): temporary image from PR #833 branch; replace with the released # quay.io/konflux-ci/release-service-utils digest once PR #833 is merged and published. image: quay.io/redhat-user-workloads/rhtap-release-2-tenant/release-service-utils-standalone@sha256:2958c29f7ebd57fe7ca54724bbc5f883946c7b4f92ed1fca810d57072fde87f0 Reference reasoning: The existing internal task definition uses the canonical `quay.io/konflux-ci/release-service-utils@sha256:...` image for this step, indicating the repo’s standard is to reference that published utility image by digest. Deviating from that pattern introduces an operational dependency on a different registry namespace and potentially different image lifecycle/permissions than the rest of the pipeline expects.
📄 References konflux-ci/release-service-catalog/tasks/internal/push-artifacts-to-cdn-task/push-artifacts-to-cdn-task.yaml [1394-1420] konflux-ci/release-service-catalog/pipelines/managed/push-artifacts-to-cdn/push-artifacts-to-cdn.yaml [109-131] konflux-ci/release-service-catalog/pipelines/managed/push-artifacts-to-cdn/push-artifacts-to-cdn.yaml [75-98] konflux-ci/release-service-catalog/pipelines/managed/push-artifacts-to-cdn/push-artifacts-to-cdn.yaml [470-478] konflux-ci/release-service-catalog/tasks/managed/push-artifacts-to-cdn/tests/test-push-artifacts-to-cdn-qa.yaml [147-171] konflux-ci/release-service-catalog/tasks/managed/push-artifacts-to-cdn/tests/test-push-artifacts-to-cdn-staging-intention.yaml [144-168] konflux-ci/release-service-catalog/tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images.yaml [1-5] konflux-ci/release-service-catalog/tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images.yaml [215-239]

qodo-app-for-konflux-ci · 2026-06-30T21:06:33Z

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (3) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 28 rules

1. ~~Multi-file scripts lack pipefail~~ ✓ Resolved 📘 Rule violation ☼ Reliability

Description

Multiple Tekton script: blocks begin with set -eu/set -ex/set -eux but omit -o pipefail,
which can mask failures in piped commands and violates the required Tekton script safety flags.

Code

tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[R60-62]
+              #!/usr/bin/env bash
+              set -eux
+

Relevance

⭐⭐ Medium
Pipefail-in-Tekton-scripts suggestions appear often but outcomes mostly undetermined; no clear
enforcement trend.
PR-#2228
PR-#2118

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 1268 requires Tekton script: blocks to enable pipefail (along with -e) at the
start of the script before any other executable commands; the cited scripts in the referenced YAML
files currently invoke set with variants like -eu, -ex, or -eux but do not include `-o
pipefail`, demonstrating non-compliance and the risk of hidden failures in pipelines.
Rule 1268: Shell scripts in Tekton tasks must start with set -eo pipefail
tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[60-64]
tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[274-279]
tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[326-329]
tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[20-22]
tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[86-90]

Agent prompt

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

## Issue description
Tekton step scripts across the referenced Pipeline/task test YAMLs start with `set -eu` / `set -ex` / `set -eux` but do not enable `-o pipefail`, which can hide failures in piped commands and violates PR Compliance ID 1268.

## Issue Context
Compliance requires Tekton task shell scripts to begin with `set -eo pipefail` (or stronger, e.g. `set -Eeuo pipefail`) before any other executable command so that pipeline failures are not masked.

## Fix Focus Areas
- tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[60-64]
- tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[274-279]
- tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[326-329]
- tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[20-22]
- tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[86-90]

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

2. Multi-file script exits 1 📘 Rule violation ≡ Correctness

Description

The Tekton check script uses exit 1 to signal business-logic/validation failure, which violates
the requirement to always exit 0 and instead report pass/fail via Tekton results.

Code

tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[R281-286]

+              artifact_count=$(echo "$artifacts" | jq 'length')
+              if [ "$artifact_count" != "2" ]; then
+                echo "Expected 2 artifact entries (one per file), got $artifact_count"
+                echo "artifacts: $artifacts"
+                exit 1
+              fi

Relevance

⭐⭐ Medium
Non-zero exit in Tekton scripts shows up in review suggestions, but acceptance/rejection not clearly
established.
PR-#2191
PR-#2213

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 1256 forbids using non-zero process exit codes for business-logic failures in
Tekton scripts; the cited scripts explicitly call exit 1 (including in multiple validation
branches), demonstrating they are communicating failure via exit status rather than via Tekton
results.
Rule 1256: Tekton task scripts must always exit 0 and use results for status
tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[281-286]
tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[94-97]

Agent prompt

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

## Issue description
Tekton `script:` steps are using `exit 1` to signal validation/business-logic failure, but compliance requires these scripts to always `exit 0` and communicate success/failure through Tekton results instead of process exit codes.

## Issue Context
PR Compliance ID 1256 forbids non-zero exits for business logic in Tekton task scripts. Update the scripts so they write pass/fail status (and any relevant messages) to result files (e.g., `$(results.<name>.path)`) while keeping the process exit code as 0.

## Fix Focus Areas
- tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[280-316]
- tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[76-97]

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

3. ~~Conforma gate bypass~~ ✓ Resolved 🐞 Bug ⛨ Security

Description

In the managed push-artifacts-to-cdn pipeline, push-artifacts-to-cdn no longer waits for
verify-conforma, so artifact publication (and downstream create-advisory) can start before policy
verification completes. This can publish non-compliant artifacts if verify-conforma later fails.

Code

pipelines/managed/push-artifacts-to-cdn/push-artifacts-to-cdn.yaml[R410-413]

          value: "$(params.quayURL)"
      runAfter:
-        - verify-conforma
        - embargo-check
    - name: create-advisory

Relevance

⭐⭐ Medium
No direct history on verify-conforma gating; but pipeline PRs treat conforma as required validation
step.
PR-#1073
PR-#2313

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The pipeline defines a verify-conforma task, but push-artifacts-to-cdn is no longer in its
dependency chain and now only waits for embargo-check, enabling publication to run before
verify-conforma completes.
pipelines/managed/push-artifacts-to-cdn/push-artifacts-to-cdn.yaml[241-268]
pipelines/managed/push-artifacts-to-cdn/push-artifacts-to-cdn.yaml[368-450]

Agent prompt

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

### Issue description
`push-artifacts-to-cdn` is no longer gated by `verify-conforma` in the managed pipeline. Because `verify-conforma` can now run in parallel, publication to CDN (and advisory creation dependent on it) may proceed before policy verification completes.

### Issue Context
This is a release-gating pipeline; publishing should not occur until Conforma policy verification has succeeded.

### Fix Focus Areas
- pipelines/managed/push-artifacts-to-cdn/push-artifacts-to-cdn.yaml[368-450]

### Expected change
- Add `verify-conforma` back to `runAfter` for `push-artifacts-to-cdn` (and any other publication-side tasks if needed) so publication cannot start until Conforma has completed successfully.

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

View more (1)

4. ~~Disk-image arch overwritten~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

The create-advisory update-purl logic for disk-image clones the first matching artifact entry as a
template for every staged file, so all generated entries inherit the same architecture/os as the
first one. If a disk-image component has staged files for multiple architectures, the advisory
artifact metadata will be wrong.

Code

tasks/managed/create-advisory/create-advisory.yaml[R319-365]

+            if [ "$content_type" = "disk-image" ]; then
+              # For disk-images, generate one advisory entry per file in staged.files[].
+              # Multiple files can share the same os+arch (e.g. ISO + QCOW2 both linux/amd64),
+              # so iterating over advisory entries (one per os+arch) would produce malformed PURLs.
+              # Instead, use the first advisory entry as a metadata template and expand it per file.
+              TEMPLATE_ENTRY=$(echo "$MATCHING_ENTRIES" | head -1)
+              # When a component has both contentGateway (Developer Portal) and staged (Customer
+              # Portal/CDN), CGW is used as the canonical download_url in the PURL. If only
+              # staged is present, the CDN URL is used instead.
+              HAS_CGW=$(jq -r 'if ((.contentGateway // {}) | length) > 0 then "true" else "false" end' \
+                <<< "$component")
+              if [ "$HAS_CGW" = "true" ]; then
+                DOWNLOAD_URL="$CGW_BASE_URL"
+              else
+                DOWNLOAD_URL="$CDN_BASE_URL"
+              fi
+
+              while IFS= read -r staged_file; do
+                FILENAME=$(jq -r '.filename' <<< "$staged_file")
+                FILENAME_BASENAME=$(basename "$FILENAME")

-                if [ "$content_type" = "disk-image" ]; then
-                  # For disk-images, we need to match the filename from the populate-release-notes step
-                  # with the staged.files[].filename that has the same architecture
-                  FILENAME=$(jq -r --arg arch "$ARCH" \
-                    '.staged.files[] | select(.filename | contains($arch)) | .filename' <<< "$component")
+                CHECKSUM=$(jq -r --arg component "$COMPONENT_NAME" --arg filename "$FILENAME_BASENAME" \
+                  '.[] | select(.component == $component) | .files[$filename] // empty' \
+                  <<< "$CHECKSUM_MAP_JSON")
+                if [ -z "$CHECKSUM" ]; then
+                  echo "Warning: No checksum found for $COMPONENT_NAME/$FILENAME_BASENAME in manifest" >&2
+                fi

-                  if [ -z "$FILENAME" ] || [ "$FILENAME" = "null" ]; then
-                    echo "Warning: No filename found for arch $ARCH in component $COMPONENT_NAME" >&2
-                    continue
-                  fi
-                else
-                  # Binary/generic files have arch/os matching, falling back to staged.files
-                  # for teams that use the CDN staged structure instead of a top-level files array
-                  FILENAME=$(jq -r --arg arch "$ARCH" --arg os "$OS" \
-                    '((.files // []) as $f
-                       | if ($f|length) > 0 then $f else (.staged.files // []) end)[]
-                       | select(.arch == $arch and .os == $os) | .source' \
-                    <<< "$component")
+                PURL="pkg:generic/$COMPONENT_NAME@$VERSION_NAME"
+                QUERY_PARAMS=()
+                # Add filename first - this uniquely identifies the file
+                if [ -n "$FILENAME_BASENAME" ]; then
+                  QUERY_PARAMS+=("filename=$FILENAME_BASENAME")
+                fi
+                if [ -n "$CHECKSUM" ]; then
+                  QUERY_PARAMS+=("checksum=$CHECKSUM")
+                fi
+                if [ -n "$DOWNLOAD_URL" ]; then
+                  QUERY_PARAMS+=("download_url=$DOWNLOAD_URL")
+                fi
+                if [ "${#QUERY_PARAMS[@]}" -gt 0 ]; then
+                  PURL="${PURL}?$(IFS=\&; echo "${QUERY_PARAMS[*]}")"
                fi

+                UPDATED_ENTRY=$(jq -c --arg purl "$PURL" '.purl = $purl' <<< "$TEMPLATE_ENTRY")
+                UPDATED_ENTRIES+=("$UPDATED_ENTRY")
+              done <<< "$(jq -c --arg name "$COMPONENT_NAME" '.[$name][]?' <<< "$SNAPSHOT_STAGED")"

Relevance

⭐⭐ Medium
No clear precedent; disk-image advisory logic sees frequent correctness fixes, so could be accepted.
PR-#1892
PR-#1347

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
create-advisory’s disk-image branch reuses the first artifact entry as a template and only changes
.purl, while populate-release-notes can emit multiple disk-image artifact entries per component
with different architecture values derived from filenames (aarch64 vs x86_64).
tasks/managed/create-advisory/create-advisory.yaml[310-366]
tasks/managed/populate-release-notes/populate-release-notes.yaml[525-564]

Agent prompt

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

### Issue description
For `content_type=disk-image`, update-purl uses the first matching advisory entry (`TEMPLATE_ENTRY`) for all staged files and only updates `.purl`. This causes all generated entries to share the template entry's `.architecture` and `.os`, corrupting metadata for components that contain multiple disk-image files across architectures.

### Issue Context
`populate-release-notes` generates one `releaseNotes.content.artifacts` entry per staged disk-image file and derives `architecture` from the filename (e.g., `aarch64` vs `x86_64`). Therefore, a single component can legitimately have multiple artifact entries with different architectures.

### Fix Focus Areas
- tasks/managed/create-advisory/create-advisory.yaml[286-366]
- tasks/managed/populate-release-notes/populate-release-notes.yaml[525-564]

### Expected change
Implement disk-image updating so that each staged file maps to an advisory entry that retains correct `architecture`/`os`, for example by:
- computing `arch` (and `os`) per staged file (matching populate-release-notes logic) and selecting the matching existing entry (by component+arch+os) to update only its `.purl`, OR
- explicitly setting `.architecture` and `.os` on `UPDATED_ENTRY` based on the staged file (or derived from filename) rather than inheriting from the first template entry.

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

5. ~~ContentType docs outdated~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The newly added disk-image test uses contentType=disk-image, but create-advisory-task still
documents contentType as only [image|binary|generic|rpm], which is now misleading for users and
maintainers. This can cause incorrect configuration and future validation/doc drift around
disk-image releases.

Code

tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[R52-53]
+        - name: contentType
+          value: "disk-image"

Relevance

⭐⭐⭐ High
Team updates contentType docs/allowlists when adding new types (e.g., added rpm and updated docs in
PR #1876).
PR-#1876

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The new test explicitly sets contentType to "disk-image", but the task’s parameter description still
claims disk-image is not an allowed option.
tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[37-54]
tasks/internal/create-advisory-task/create-advisory-task.yaml[41-44]

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 internal `create-advisory-task` parameter docs for `contentType` still list only `[image|binary|generic|rpm]`, but this PR introduces disk-image usage (`contentType: "disk-image"`) via a new test. This inconsistency is confusing and will lead to incorrect user configuration.

## Issue Context
Disk-image support is being added end-to-end, so the task’s parameter documentation should reflect the supported values.

## Fix Focus Areas
- tasks/internal/create-advisory-task/create-advisory-task.yaml[41-44]

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

6. README missing for YAML changes 📘 Rule violation ≡ Correctness

Description

Tekton YAML files under tasks/ and pipelines/ were modified but the corresponding generated
README.md files in those directories were not updated in this PR. This indicates the README
regeneration step was likely skipped.

Code

tasks/managed/create-advisory/create-advisory.yaml[R286-295]

+        # Build a name → staged.files lookup from the snapshot.  apply-mapping substitutes
+        # {{ release_timestamp }} (and other template vars) in the snapshot's components but
+        # does NOT write those substitutions back to the data file.  Reading staged.files from
+        # DATA_FILE would produce filenames like "foo-{{ release_timestamp }}-x86_64.iso" which
+        # Jinja2 would then render as empty, giving "foo--x86_64.iso" in the advisory.
+        SNAPSHOT_FILE="$(params.dataDir)/$(params.snapshotPath)"
+        SNAPSHOT_STAGED=$(jq -c \
+          'reduce .components[] as $c ({}; .[$c.name] = ($c.staged.files // []))' \
+          "$SNAPSHOT_FILE")
+

Relevance

⭐⭐⭐ High
README regeneration is actively requested when Tekton YAML changes (e.g., “regenerate README”
suggestions in PR #2270).
PR-#2270

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 494 requires the README to be regenerated when Tekton YAML under tasks/ or
pipelines/ is modified. This PR changes those YAML files, while the corresponding READMEs remain
present in the repo and are not part of the diff.
Rule 494: README must be regenerated when Tekton YAML is modified
tasks/managed/create-advisory/create-advisory.yaml[286-295]
tasks/managed/create-advisory/README.md[1-5]

Agent prompt

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

## Issue description
Tekton YAML under `tasks/`/`pipelines/` changed without updating the corresponding `README.md` outputs.

## Issue Context
Compliance requires regenerating the README when the Tekton YAML source changes.

## Fix Focus Areas
- tasks/managed/create-advisory/create-advisory.yaml[286-295]
- pipelines/managed/push-artifacts-to-cdn/push-artifacts-to-cdn.yaml[295-299]
- tasks/managed/push-artifacts-to-cdn/push-artifacts-to-cdn.yaml[132-136]

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

7. Tenant image registry dependency 🐞 Bug ☼ Reliability

Description

The internal push-artifacts-to-cdn task now uses a release-service-utils image hosted under a
tenant-specific quay.io/redhat-user-workloads repository rather than the repo’s typical
quay.io/konflux-ci location. This introduces an environment dependency (image
availability/mirroring/trust policy) that can break task execution in clusters where that repository
isn’t accessible or approved.

Code

tasks/internal/push-artifacts-to-cdn-task/push-artifacts-to-cdn-task.yaml[182]
+      image: quay.io/redhat-user-workloads/rhtap-release-2-tenant/release-service-utils-standalone@sha256:2958c29f7ebd57fe7ca54724bbc5f883946c7b4f92ed1fca810d57072fde87f0

Relevance

⭐⭐ Medium
No clear precedent rejecting tenant-scoped images; repo has merged redhat-user-workloads image refs
(PR #1821).
PR-#1821

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The modified internal task step now references a tenant-scoped image, while other catalog tasks in
this repo continue to reference quay.io/konflux-ci release-service-utils images, indicating this is
a one-off dependency introduced by the PR.
tasks/internal/push-artifacts-to-cdn-task/push-artifacts-to-cdn-task.yaml[180-186]
tasks/managed/create-advisory/create-advisory.yaml[159-162]
tasks/internal/create-advisory-task/create-advisory-task.yaml[88-91]

Agent prompt

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

## Issue description
`push-artifacts-to-cdn-task` switched to a tenant-scoped `quay.io/redhat-user-workloads/...` release-service-utils image. This differs from the rest of the catalog (which references `quay.io/konflux-ci/...`) and creates an operational dependency on that registry/repository.

## Issue Context
If this change is temporary (e.g., pending release-service-utils PR 833), it should be clearly documented with a TODO and/or reverted to the standard image once the released digest is available.

## Fix Focus Areas
- tasks/internal/push-artifacts-to-cdn-task/push-artifacts-to-cdn-task.yaml[181-183]

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

View more (1)

8. ~~Bare $artifact_count expansion~~ ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

The script uses bare variable expansions like $artifact_count instead of brace form
${artifact_count}. This can create ambiguity in concatenation contexts and violates the required
brace expansion style.

Code

tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[R283-285]

+                echo "Expected 2 artifact entries (one per file), got $artifact_count"
+                echo "artifacts: $artifacts"
+                exit 1

Relevance

⭐⭐ Medium
Brace-style shell expansion suggested in similar tests (PR 2318) but no definitive
acceptance/rejection evidence.
PR-#2318

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 1264 requires brace syntax for shell variable expansion; the script prints
variables using bare $... expansions.
Rule 1264: Use brace syntax for shell variable expansion
tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[283-285]

Agent prompt

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

## Issue description
Shell variables are expanded without brace syntax (e.g., `$artifact_count`).

## Issue Context
Compliance requires non-special shell variables to be referenced as `${VAR}`.

## Fix Focus Areas
- tasks/managed/create-advisory/tests/test-create-advisory-update-purl-disk-images-multi-file.yaml[281-316]

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

9. advisory_json base64 line too long ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

A newly added YAML line embeds a very long base64 payload in a single echo -n command, exceeding
the 120 character limit. This hurts readability and violates the YAML formatting requirement.

Code

tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[30]

+              echo -n H4sIAAAAAAAAA12RT2sCMRDF736KJeeadbVIWShtb0IvxR6LSEjGdXA3CclsUcTv3vxD1p6SvN+bNzPkOqsqZp1Ro6Q9KtZWzXL1NBW1GCDIbAuq2giqvrLOHky/4DwaHX0NX/LVI/XkQAwRkm0ykjaFhqOtRQtnMdge2lLQQv+SbXTJvu3m+yMr/qKN9ehTGniq7kIuMBblneVXAgq8dGipTJnwVMvhph8fHHchYQcHcKAlxO4/7EhkfVvXykjPywpcmqHWJhSzXV7UaAJNoeAankEQjvAgJKWMJFUFFSyPSCBpdGnz88t6v35O/YvDpN171ON5KofG1ujcKg0/V+hPcxxEB1OfHV0fLfbUtR1ocCjrf/b3hi/44u2APcTff004EY7eTMM8dhp19wmXGOlAHUX46x6EhyUrtls6d7N4u/0BSEfEJnACAAA= \

Relevance

⭐ Low
Similar 120-char YAML line-length fixes were rejected (e.g., fold long image refs) in PR #2197.
PR-#2197

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 1252 requires YAML lines to be <=120 characters. The added echo -n line contains
a long base64 string on a single YAML line, clearly exceeding the limit.
Rule 1252: Limit YAML line length to 120 characters
tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[30-30]

Agent prompt

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

## Issue description
A line in a changed YAML file exceeds 120 characters due to an inline base64 blob.

## Issue Context
Rule requires YAML lines to be wrapped/folded to <= 120 characters.

## Fix Focus Areas
- tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml[22-31]

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

10. Image line exceeds 120 📘 Rule violation ⚙ Maintainability

Description

A modified YAML line exceeds the 120 character limit due to a very long image: reference. This
reduces readability and violates the configured YAML formatting standard.

Code

tasks/internal/push-artifacts-to-cdn-task/push-artifacts-to-cdn-task.yaml[182]
+      image: quay.io/redhat-user-workloads/rhtap-release-2-tenant/release-service-utils-standalone@sha256:2958c29f7ebd57fe7ca54724bbc5f883946c7b4f92ed1fca810d57072fde87f0

Relevance

⭐ Low
Similar “wrap long image line / 120-char” suggestion was explicitly rejected in PR 2197.
PR-#2197

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 1252 requires YAML lines to be limited to 120 characters; the updated image: line
is a single very long line containing a full image reference with a SHA digest.
Rule 1252: Limit YAML line length to 120 characters
tasks/internal/push-artifacts-to-cdn-task/push-artifacts-to-cdn-task.yaml[182-182]

Agent prompt

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

## Issue description
A changed YAML line exceeds 120 characters (`image:` value is too long).

## Issue Context
Compliance requires YAML visible line length <= 120 characters.

## Fix Focus Areas
- tasks/internal/push-artifacts-to-cdn-task/push-artifacts-to-cdn-task.yaml[182-182]

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

qodo-app-for-konflux-ci · 2026-07-01T13:06:36Z

Code review by qodo was updated up to the latest commit 1b7a471

- push-artifacts-to-cdn pipeline: update release-service-utils image to PR 833 build - create-advisory-task: add disk-image to contentType allowlist, routing it to .content.artifacts - create-advisory: fix PURL generation for disk images - generate one entry per staged file instead of per os+arch advisory entry - create-advisory: fix dedup for disk-image artifacts - replace entries rather than map-merge to retain multiple files per component Assisted-by: Cursor AI Signed-off-by: Scott Wickersham <swickers@redhat.com>

qodo-app-for-konflux-ci · 2026-07-01T16:54:30Z

Code review by qodo was updated up to the latest commit 9e2cf39

FilipNikolovski

lgtm

github-actions Bot added the ai-assisted label Jun 27, 2026

swickersh force-pushed the release-2460 branch 6 times, most recently from ae32227 to 53c8628 Compare June 30, 2026 19:16

swickersh mentioned this pull request Jun 30, 2026

feat(RELEASE-2460): add disk-image support to artifact helpers konflux-ci/release-service-utils#833

Open

swickersh force-pushed the release-2460 branch from 53c8628 to b36ab85 Compare June 30, 2026 20:29

swickersh changed the title ~~WIP - Release 2460~~ feat(RELEASE-2460): add disk-image support to push-artifacts-to-cdn Jun 30, 2026

swickersh force-pushed the release-2460 branch from b36ab85 to d83cfa4 Compare June 30, 2026 20:54

swickersh marked this pull request as ready for review June 30, 2026 20:56

swickersh requested review from arewm, gbenhaim, ralphbean and twaugh as code owners June 30, 2026 20:56

release-service-bot assigned FilipNikolovski and theflockers Jun 30, 2026

qodo-app-for-konflux-ci Bot added the Review effort 3/5 label Jun 30, 2026

qodo-app-for-konflux-ci Bot reviewed Jun 30, 2026

View reviewed changes

swickersh force-pushed the release-2460 branch 2 times, most recently from 30ccbc1 to 1b7a471 Compare July 1, 2026 12:55

qodo-app-for-konflux-ci Bot reviewed Jul 1, 2026

View reviewed changes

Comment thread tasks/managed/create-advisory/create-advisory.yaml

Comment thread tasks/internal/create-advisory-task/tests/test-create-advisory-disk-image-content.yaml

Comment thread tasks/internal/push-artifacts-to-cdn-task/push-artifacts-to-cdn-task.yaml

swickersh force-pushed the release-2460 branch from 1b7a471 to 9e2cf39 Compare July 1, 2026 15:47

qodo-app-for-konflux-ci Bot added the Possible security concern label Jul 1, 2026

FilipNikolovski reviewed Jul 2, 2026

View reviewed changes

Comment thread tasks/internal/push-artifacts-to-cdn-task/push-artifacts-to-cdn-task.yaml

FilipNikolovski approved these changes Jul 2, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(RELEASE-2460): add disk-image support to push-artifacts-to-cdn#2334

feat(RELEASE-2460): add disk-image support to push-artifacts-to-cdn#2334
swickersh wants to merge 1 commit into
konflux-ci:developmentfrom
swickersh:release-2460

swickersh commented Jun 27, 2026 •

edited

Loading

Uh oh!

qodo-app-for-konflux-ci Bot commented Jun 30, 2026 •

edited

Loading

Uh oh!

qodo-app-for-konflux-ci Bot commented Jun 30, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

qodo-app-for-konflux-ci Bot commented Jul 1, 2026

Uh oh!

qodo-app-for-konflux-ci Bot commented Jul 1, 2026

Uh oh!

Uh oh!

FilipNikolovski left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

swickersh commented Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist before requesting a review

Uh oh!

qodo-app-for-konflux-ci Bot commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Reviewer Guide 🔍

(Review updated until commit 9e2cf39)

Uh oh!

qodo-app-for-konflux-ci Bot commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

qodo-app-for-konflux-ci Bot commented Jul 1, 2026

Uh oh!

qodo-app-for-konflux-ci Bot commented Jul 1, 2026

Uh oh!

Uh oh!

FilipNikolovski left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

swickersh commented Jun 27, 2026 •

edited

Loading

qodo-app-for-konflux-ci Bot commented Jun 30, 2026 •

edited

Loading

(Review updated until commit `9e2cf39`)

qodo-app-for-konflux-ci Bot commented Jun 30, 2026 •

edited

Loading