feat: add dual-compression (zstd:chunked) to buildah task

[Amanyd]

Add COMPRESSION_FORMAT (gzip|zstd-chunked|dual) and FORCE_COMPRESSION params. In dual mode, push gzip and zstd:chunked variants bundled in a per-arch OCI index (gzip first). The IMAGES result exposes both child manifest refs for Chains provenance. SBOM generation, signing, and SBOM attachment run for each variant.

Default stays gzip; dual requires BUILDAH_FORMAT=oci.

Ref: #1264
Ref: https://github.com/konflux-ci/architecture/blob/main/ADR/0070-dual-compression-for-container-builds.md

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 6:43 AM UTC · Completed 6:53 AM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

Review — comment

PR: feat: add dual-compression (zstd:chunked) to buildah task
Scope: Authorized via #1264 and ADR-0070. Adds COMPRESSION_FORMAT (gzip|zstd-chunked|dual) and FORCE_COMPRESSION params to all 5 buildah task variants with corresponding SBOM, signing, and provenance support.

Summary

This is a well-structured feature addition. The design is clean: default behavior is preserved (gzip), the dual mode is properly guarded behind a BUILDAH_FORMAT=oci requirement, and all produced artifacts (index + both compression children) are signed and receive SBOMs. Security review found no issues — all params are properly mapped to env vars before script use, and the COMPRESSION_FORMAT value is validated via a case allowlist before any command use.

The findings below are non-blocking observations for a feature correctly labeled as "tech preview."

---

Findings

1. [medium] No test coverage for dual-compression logic

Category: test-adequacy
File: N/A

The dual-mode code path has significant complexity — two pushes, manifest index creation, index push (twice), three SBOM generations, three signings, and three SBOM uploads. No e2e or integration tests cover COMPRESSION_FORMAT or FORCE_COMPRESSION. The existing e2e tests in e2e-tests/tests/build/build_templates.go don't exercise this path.

For tech preview this is acceptable, but before promoting to GA, at minimum a happy-path e2e test for dual mode should validate that: (a) the per-arch index resolves correctly, (b) both child manifests are pullable, and (c) SBOMs are attached to all three refs.

2. [medium] buildah manifest inspect → mobster oci-index format contract is unverified

Category: cross-component-contract
File: task/buildah-oci-ta/0.10/buildah-oci-ta.yaml (and all variants)

The push step saves buildah manifest inspect output to /shared/per-arch-index-manifest.json. The prepare-sboms step then passes this to mobster oci-index --index-manifest-path. Whether the buildah manifest inspect JSON schema matches what mobster expects cannot be verified from this repository. If there's a format mismatch, the index SBOM generation will fail or produce an incorrect SBOM.

Remediation: Validate through integration testing or by checking mobster's expected schema for --index-manifest-path.

3. [low] FORCE_COMPRESSION=true with COMPRESSION_FORMAT=gzip silently does nothing

Category: edge-case
File: task/buildah-oci-ta/0.10/buildah-oci-ta.yaml (and all variants)

The guard [ "${FORCE_COMPRESSION}" = "true" ] && [ "${COMPRESSION_FORMAT}" != "gzip" ] means setting FORCE_COMPRESSION=true with the default gzip format has no effect and produces no warning. The documentation says "Only applies to zstd-chunked and dual modes," so this is by design. A user who explicitly sets the flag with gzip may be surprised. Consider emitting a log message in this case.

4. [low] Intermediate tags accumulate in the registry

Category: resource-hygiene
File: task/buildah-oci-ta/0.10/buildah-oci-ta.yaml (and all variants)

In dual mode, three intermediate tags are pushed: ${TASKRUN_NAME}-gzip, ${TASKRUN_NAME}-zstd, and ${TASKRUN_NAME}. None are cleaned up. The single ${TASKRUN_NAME} tag was already not cleaned up (pre-existing pattern), so this adds two more per build. If IMAGE_EXPIRES_AFTER is set, verify the expiry label covers these intermediate tags.

5. [low] Validation ordering: case statement runs after compression_args construction

Category: defense-in-depth
File: task/buildah-oci-ta/0.10/buildah-oci-ta.yaml (and all variants)

The compression_args array is populated before the case statement that validates COMPRESSION_FORMAT. An invalid value would leave compression_args empty and then fail at the case statement, so there's no functional impact. Moving the case validation first would be a minor defense-in-depth improvement.

---

Positive observations

• Correct Tekton security pattern: All params mapped to env vars via stepTemplate.env or step-level env before use in scripts.
• Complete signing coverage: All three refs (index + gzip child + zstd child) are signed in dual mode.
• Complete SBOM coverage: Per-variant SBOMs generated with correct digests, plus an index SBOM using mobster oci-index.
• Backward compatible: Default gzip preserves existing behavior. New optional params don't break existing pipelines.
• Proper versioning: 0.10.4 → 0.10.5 patch bump across all 5 variants with consistent changelogs.
• Comprehensive docs: All task READMEs, pipeline READMEs, and CHANGELOGs updated.
• Cross-repo safety: Existing IMAGE_DIGEST, IMAGE_URL, IMAGE_REF results maintain their semantics. The new IMAGES result is additive.

Previous run

Review — Approve

PR: #3682 — feat: add dual-compression (zstd:chunked) to buildah task
Author: Amanyd | Status: Draft | Verdict: approve

Summary

This PR adds dual-compression support (gzip + zstd:chunked) across all five buildah task variants (buildah, buildah-oci-ta, buildah-oci-ta-min, buildah-remote, buildah-remote-oci-ta). The feature allows pushing both a gzip and zstd:chunked variant of an image, bundled together in a per-arch OCI index (gzip first for backward compatibility). The default remains gzip, so existing users are unaffected.

What was verified:

• Env-var wiring is correct: COMPRESSION_FORMAT is added to stepTemplate.env in all five tasks (available to build, push, prepare-sboms, and upload-sbom steps). FORCE_COMPRESSION is scoped to the push step only, which is the only step that needs it. The remote builder tasks correctly pass COMPRESSION_FORMAT via SSH for the remote build context.
• Input validation is sound: COMPRESSION_FORMAT is validated via a case statement (only gzip, zstd-chunked, dual accepted). The dual→OCI requirement is enforced with an early exit. FORCE_COMPRESSION uses safe string comparison against "true".
• Signing covers all variants: In dual mode, the index plus both child manifests (gzip, zstd) are signed with cosign. Credentials are correctly selected from the first ref.
• SBOM generation handles all variants: A generate_oci_image_sbom() function extracts the common SBOM logic. In dual mode, three SBOMs are generated (gzip child, zstd child, per-arch index via oci-index), each attached and attested to its correct image ref.
• Results are consistent: IMAGE_DIGEST/IMAGE_URL/IMAGE_REF point to the per-arch index in dual mode. The new IMAGES result carries the individual child refs for Chains provenance. In non-dual mode, IMAGES echoes the single ref from IMAGE_REF.
• Backward compatibility is preserved: The default COMPRESSION_FORMAT=gzip exercises the existing code path with no behavioral change (the only difference: IMAGES result is now also populated in gzip mode).
• Tekton security rule followed: Parameters are never interpolated directly in scripts — all flow through env vars per .cursor/rules/tekton.mdc.
• Version bumps, CHANGELOGs, and README updates are present and consistent across all five task variants (0.10.4 → 0.10.5).

Observations

1. SBOM pullspec variable inconsistency — In dual mode, generate_oci_image_sbom is called with $IMAGE (stepTemplate env var) as the pullspec. In non-dual mode, it uses $IMAGE_URL (read from the results file). Both resolve to the same value (the push step writes echo -n "$IMAGE" | tee $(results.IMAGE_URL.path)), so this is functionally identical, but using $IMAGE_URL consistently would align with the non-dual path and reinforce the pattern of reading from results.

2. No tests for new code paths — The PR adds ~150 lines of new shell logic per variant covering three compression modes, but no automated tests are included. Given this is tagged as tech preview, integration test coverage for dual and zstd-chunked modes would help prevent regressions when the feature graduates. Consider tracking this as a follow-up.

3. Code duplication across task variants — The dual-compression logic (~150 lines across push, signing, SBOM, and upload steps) is replicated identically in all five task YAML files. This is consistent with the repo's existing pattern (these tasks have always been maintained as copies), but it increases the maintenance surface. Worth considering whether task-generator or a shared script could reduce divergence risk.

No Blocking Findings

The change is well-structured, properly error-handled, and backward-compatible. The tech preview designation and draft status are appropriate for this stage. Approving for merge readiness review by the build-maintainers team.

Previous run (2)

Review — comment

PR: feat: add dual-compression (zstd:chunked) to buildah task
Status: Draft · 1522 additions, 523 deletions across 15 files
Authorization: ✅ Traced to issue #1264 and ADR 0070

Summary

This PR adds COMPRESSION_FORMAT (gzip|zstd-chunked|dual) and FORCE_COMPRESSION parameters plus a new IMAGES result to all five buildah task variants. The dual-mode implementation is well-structured: it pushes gzip and zstd:chunked variants, bundles them in a per-arch OCI index (gzip first for backward compatibility), signs all three images, generates per-variant SBOMs, and attaches/signs them. The code correctly validates COMPRESSION_FORMAT before use, enforces the OCI format requirement for dual mode, and follows the Tekton security rule (env vars, not $(params.*) in scripts).

The implementation aligns with ADR 0070's design. No critical or high-severity issues were found in the logic or security surface. The findings below are process compliance and design-level observations appropriate for a draft PR.

---

Findings

1. Version bump required — app.kubernetes.io/version not updated

Severity: medium · Category: versioning

All five task YAML files remain at version 0.10.4. Per tekton.mdc: "Each meaningful change to a task must include a version bump." Adding two parameters and a result is a meaningful change.

Files: task/buildah/0.10/buildah.yaml, task/buildah-oci-ta/0.10/buildah-oci-ta.yaml, task/buildah-oci-ta-min/0.10/buildah-oci-ta-min.yaml, task/buildah-remote/0.10/buildah-remote.yaml, task/buildah-remote-oci-ta/0.10/buildah-remote-oci-ta.yaml

Remediation: Bump to 0.10.5 (patch for non-breaking additive change at 0.x) across all five variants.

---

2. CHANGELOG not updated for any variant

Severity: medium · Category: changelog

All five CHANGELOG.md files show "Nothing yet" under Unreleased. Per tekton.mdc: "Update the task's CHANGELOG.md with each version bump. Group changes by type (added, changed, fixed, removed)."

Files: task/buildah/CHANGELOG.md, task/buildah-oci-ta/CHANGELOG.md, task/buildah-oci-ta-min/CHANGELOG.md, task/buildah-remote/CHANGELOG.md, task/buildah-remote-oci-ta/CHANGELOG.md

Remediation: Add a ## 0.10.5 section with:

### Added
- COMPRESSION_FORMAT parameter: gzip (default), zstd-chunked, or dual compression
- FORCE_COMPRESSION parameter: recompress all layers including base-image layers
- IMAGES result: comma-separated manifest refs for Chains provenance in dual mode

---

3. SBOM_BLOB_URL semantics in dual mode

Severity: low · Category: design

In dual mode, SBOM_BLOB_URL is computed from sha256sum sbom-index.json (the index-level SBOM). Downstream provenance verification (Enterprise Contract) currently expects a single SBOM reference per image. If EC policies need per-variant SBOM blob URLs, the single SBOM_BLOB_URL result would be insufficient.

Remediation: Verify with the EC policy team that the index-level SBOM reference is the correct provenance anchor for dual-mode builds. If per-variant references are needed, consider emitting additional results or updating documentation to clarify the expected verification flow.

---

4. IMAGES result naming may cause confusion with build-image-index

Severity: low · Category: naming

The new IMAGES result on buildah tasks shares a name with the build-image-index task's IMAGES parameter and result. While they're on different tasks (no direct collision), the semantic overlap could confuse users. The pipeline wiring currently feeds IMAGE_REF → build-image-index:IMAGES, not the new IMAGES result.

Remediation: Consider documenting the distinction clearly, or renaming to CHILD_IMAGES or COMPRESSION_VARIANT_REFS to avoid ambiguity.

---

5. Cross-variant formatting inconsistency in case statements

Severity: low · Category: style

The COMPRESSION_FORMAT validation case statement uses compact single-line format in buildah.yaml and buildah-remote.yaml but expanded multi-line format in the oci-ta variants. This mirrors pre-existing formatting differences in the SBOM_TYPE case statement and is not a functional issue, but it complicates future diff-based consistency checks across variants.

---

6. generate_oci_image_sbom() introduces a new shell function pattern

Severity: low · Category: style

All existing task scripts use inline logic with no function definitions. The new generate_oci_image_sbom() function is a readability improvement (avoids duplicating the mobster invocation for gzip/zstd variants) but is a departure from the existing pattern. This is a reasonable evolution — the function correctly captures all parameters from the outer scope and reduces code duplication within the SBOM generation section.

---

Verified ✅

• Parameter-to-env mapping: Both COMPRESSION_FORMAT and FORCE_COMPRESSION are mapped to env vars via stepTemplate.env or step-level env blocks. Neither is used as $(params.*) in scripts, satisfying the Tekton security rule.
• COMPRESSION_FORMAT validation: The case statement validates before any command interpolation. Invalid values cause exit 1.
• OCI format guard: Dual mode correctly checks push_format != oci and errors early.
• Remote task SSH propagation: COMPRESSION_FORMAT is passed via -e flag to the remote builder. FORCE_COMPRESSION is correctly omitted from SSH (only needed in the local push step).
• Signing coverage: All three images (index + gzip child + zstd child) are signed in dual mode.
• SBOM per-variant generation: Separate SBOMs are generated and attached for each compression variant.
• Backward compatibility: Defaults (gzip, false) preserve existing behavior for all current users.
• Gzip-first ordering: The per-arch index adds gzip before zstd, per ADR 0070.
• Authorization: Properly linked to issue Add zstd:chunked compression to built images. #1264 and ADR 0070.

---

Labels: PR adds new compression format parameters to buildah tasks

Previous run (3)

Review — comment

PR: #3682
Status: Draft
Scope: Adds dual-compression (zstd:chunked + gzip) support to all buildah task variants, implementing the approach described in issue #1264 (Idea 2) and ADR-0070.

What the PR does

Introduces two new parameters (COMPRESSION_FORMAT, FORCE_COMPRESSION) across five buildah task variants and their pipeline READMEs. In dual mode, the push step:

1. Pushes gzip and zstd:chunked variants separately, obtaining individual digests
2. Creates a per-arch OCI index (gzip first for backward compatibility)
3. Pushes the index to both the TaskRun-based and git-revision-based tags
4. Exposes child manifest refs via a new IMAGES result for Chains provenance
5. Signs all three artifacts (index + both children)
6. Generates and attaches separate SBOMs for each variant plus the index

The implementation correctly validates that dual requires BUILDAH_FORMAT=oci, rejects unknown format values, and preserves existing behavior when COMPRESSION_FORMAT=gzip (default).

Architecture assessment

The approach is sound: building once and pushing twice with different compression avoids rebuilding and keeps the image layers identical. The per-arch OCI index correctly bundles both variants with gzip first, maintaining backward compatibility with pre-2023 Docker clients. The SBOM and signing logic properly extends to cover all variants, maintaining the provenance chain.

The new IMAGES result is correctly additive — it doesn't replace IMAGE_REF (which continues to point to the index) and is not yet wired to downstream pipeline parameters, appropriate for a tech preview.

Findings

1. No test coverage for new compression modes — medium

Files: All five task YAML files
Category: test-adequacy

The PR adds ~120 lines of non-trivial shell logic per task variant (push branching, manifest creation, multi-variant signing, SBOM generation) with no corresponding test changes. There are no e2e tests for:

• COMPRESSION_FORMAT=dual end-to-end flow
• COMPRESSION_FORMAT=zstd-chunked (standalone mode)
• FORCE_COMPRESSION=true behavior
• Error path validation (dual + docker format rejection)

Given this is a draft and marked as tech preview, tests may be planned for a follow-up. However, the complexity of the dual-mode push/sign/SBOM flow (manifest creation, multi-artifact signing, index SBOM generation) warrants dedicated test coverage before leaving draft status.

Remediation: Add e2e tests exercising COMPRESSION_FORMAT=dual with OCI format, verifying that the per-arch index contains both variants, both children are signed, SBOMs are attached to all three references, and the IMAGES result contains the expected comma-separated refs.

2. buildah manifest add lacks explicit error handling — low

Files: task/buildah-oci-ta-min/0.10/buildah-oci-ta-min.yaml, task/buildah-oci-ta/0.10/buildah-oci-ta.yaml, task/buildah-remote-oci-ta/0.10/buildah-remote-oci-ta.yaml, task/buildah-remote/0.10/buildah-remote.yaml, task/buildah/0.10/buildah.yaml
Category: error-handling

The buildah manifest add calls use retry but without the if ! retry ... then echo "Failed to..." >&2; exit 1; fi pattern used consistently for all buildah push calls:

buildah manifest create "$per_arch_index"
retry buildah manifest add "$per_arch_index" "docker://${gzip_ref}"
retry buildah manifest add "$per_arch_index" "docker://${zstd_ref}"

While set -euo pipefail catches failures, the error message would be opaque compared to the explicit messages on push failures. Similarly, buildah manifest create is not wrapped with retry (acceptable since it's local) but also has no explicit error message.

Remediation: Wrap manifest add calls in the same if ! retry ... then echo "Failed to add ... to manifest" >&2; exit 1; fi pattern for consistency and debuggability.

3. Temporary compression variant tags not cleaned up — low

Files: All five task YAML files
Category: resource-management

Dual mode pushes three tags per build: ${TASKRUN_NAME}-gzip, ${TASKRUN_NAME}-zstd, and ${TASKRUN_NAME} (index). The existing behavior already leaves ${TASKRUN_NAME} tags behind, so this follows the established pattern, but dual mode triples the number of orphaned tags per build.

Remediation: Consider adding cleanup of the -gzip and -zstd temporary tags after the index is successfully pushed. This could be a follow-up improvement across all modes.

4. Minor formatting inconsistency in case statements across task variants — low

Files: task/buildah/0.10/buildah.yaml, task/buildah-remote/0.10/buildah-remote.yaml vs oci-ta variants
Category: style

The case statement for COMPRESSION_FORMAT validation uses single-line format in the non-oci-ta tasks:

case "${COMPRESSION_FORMAT}" in
  gzip|zstd-chunked|dual) ;;
  *) echo "ERROR: ..." >&2; exit 1 ;;
esac

But multi-line format in the oci-ta tasks:

case "${COMPRESSION_FORMAT}" in
gzip | zstd-chunked | dual) ;;
*)
  echo "ERROR: ..." >&2
  exit 1
  ;;
esac

Remediation: Normalize the formatting across all five task files for consistency.

Positive observations

• Input validation is thorough: Invalid COMPRESSION_FORMAT values are rejected, and dual without OCI format correctly errors early.
• Backward compatibility preserved: Default stays gzip; all existing results (IMAGE_DIGEST, IMAGE_URL, IMAGE_REF, SBOM_BLOB_URL) maintain their semantics.
• Signing coverage is complete: All three artifacts (index + both children) are individually signed with cosign, maintaining the provenance chain.
• SBOM coverage is complete: Separate SBOMs for gzip child, zstd child, and index are generated and attached, with the index using oci-index mode.
• Documentation is accurate: READMEs are updated for all affected pipelines and tasks with correct parameter descriptions and the appropriate "tech preview" disclaimer.
• gzip-first ordering in the manifest index ensures backward compatibility with older Docker clients.

Previous run (4)

Review — request-changes

PR: feat: add dual-compression (zstd:chunked) to buildah task
Status: Draft

Summary

This PR adds dual-compression support (gzip + zstd:chunked) across all five buildah task variants (buildah, buildah-oci-ta, buildah-oci-ta-min, buildah-remote, buildah-remote-oci-ta). The implementation introduces two new optional parameters (COMPRESSION_FORMAT, FORCE_COMPRESSION) and a new IMAGES result. In dual mode, the task pushes gzip and zstd:chunked variants as separate manifests, bundles them in a per-arch OCI index, signs all three artifacts, and generates/attaches separate SBOMs for each.

The core logic is well-structured: input validation is thorough, the OCI-format guard for dual mode is correct, error handling follows existing patterns, and signing/SBOM coverage for all variants is complete. Parameters are correctly plumbed through env vars (not $(params.*) interpolation in scripts), following the project's Tekton security conventions.

However, the PR is missing required version and changelog updates per the project's task versioning policy.

---

Findings

1. Missing version bump — all five task YAML files (medium)

All five task files retain app.kubernetes.io/version: "0.10.4". Per .cursor/rules/tekton.mdc and ADR 0054:

Each meaningful change to a task must include a version bump in the app.kubernetes.io/version label.

This is a significant feature addition (new params, new result, new dual-push/sign/SBOM logic). Without a version bump, the task bundles will not be rebuilt, and this feature will not be deployed.

Affected files:

• task/buildah/0.10/buildah.yaml (line 5)
• task/buildah-oci-ta/0.10/buildah-oci-ta.yaml (line 10)
• task/buildah-oci-ta-min/0.10/buildah-oci-ta-min.yaml (line 9)
• task/buildah-remote/0.10/buildah-remote.yaml (line 8)
• task/buildah-remote-oci-ta/0.10/buildah-remote-oci-ta.yaml (line 8)

Remediation: Bump version to 0.10.5 in all five files. Version numbers must match across all variants.

2. Missing CHANGELOG updates — all five task CHANGELOGs (medium)

None of the task CHANGELOGs are updated. Per the project's conventions:

Update the task's CHANGELOG.md with each version bump. Group changes by type (added, changed, fixed, removed).

Affected files:

• task/buildah/CHANGELOG.md
• task/buildah-oci-ta/CHANGELOG.md
• task/buildah-oci-ta-min/CHANGELOG.md
• task/buildah-remote/CHANGELOG.md
• task/buildah-remote-oci-ta/CHANGELOG.md

Remediation: Add entries under ## 0.10.5 documenting:

• Added: COMPRESSION_FORMAT parameter (gzip, zstd-chunked, dual)
• Added: FORCE_COMPRESSION parameter
• Added: IMAGES result for Chains provenance in dual mode

3. SBOM pullspec inconsistency in dual mode — all five task YAML files (low)

In the generate_oci_image_sbom function, the non-dual path passes $IMAGE_URL as the pullspec:

generate_oci_image_sbom sbom.json "$IMAGE_DIGEST" "$IMAGE_URL"

But the dual path passes $IMAGE instead:

generate_oci_image_sbom sbom-gzip.json "$gzip_digest" "$IMAGE"
generate_oci_image_sbom sbom-zstd.json "$zstd_digest" "$IMAGE"

Although IMAGE_URL is set from IMAGE and they have the same value, this is inconsistent with the established pattern. Consider using $IMAGE_URL (read from the result file) or $IMAGE consistently in both paths.

4. Orphaned temporary tags in registry — all five task YAML files (low)

In dual mode, the gzip and zstd variants are pushed to temporary tags (${TASKRUN_NAME}-gzip, ${TASKRUN_NAME}-zstd). These tags are used to obtain the digest references for the per-arch index, but they are never cleaned up after the index is pushed. Over time, these orphaned tags will accumulate in the registry.

Remediation: Consider documenting the cleanup expectation (e.g., registry garbage collection or tag expiration policy), or adding tag cleanup after the index push succeeds.

---

Positive observations

• Input validation is thorough: the case statement rejects unknown compression formats, and the OCI format guard prevents dual with docker format.
• Signing coverage correctly signs all three artifacts (index + both child manifests) in dual mode.
• SBOM coverage generates separate SBOMs for each variant and a separate index SBOM, all properly attached and signed.
• Backward compatibility is preserved: default gzip behavior is unchanged, and the new parameters are optional.
• Security: parameters are correctly plumbed through Tekton env vars in stepTemplate (not directly interpolated in scripts).
• Consistency: the same logic is applied consistently across all five buildah task variants.

Previous run (5)

Review — comment

PR: #3682 · Status: Draft
Author: Amanyd · Base: main

Summary

This PR adds dual-compression (zstd:chunked) support to all 5 buildah task variants. Two new optional parameters (COMPRESSION_FORMAT, FORCE_COMPRESSION) and a new IMAGES result are added. In dual mode, both gzip and zstd:chunked variants are pushed and bundled into a per-arch OCI index. Signing, SBOM generation, and SBOM attachment are extended to cover all variants.

The implementation is well-structured: input validation exists via case statements, parameters are correctly wired through env vars (not $(params.*) in scripts), SSH forwarding in remote variants includes COMPRESSION_FORMAT with @Q quoting, and error handling follows existing patterns with set -euo pipefail.

Default behavior (gzip) is preserved — no backward-incompatible changes for existing users.

Findings

1. Dual-mode semantic contract change for IMAGE_DIGEST and IMAGE_REF (medium — cross-repo-contracts)

Files: all 5 buildah*.yaml task files

In dual mode, IMAGE_DIGEST transitions from a manifest digest to an OCI index digest, and IMAGE_REF similarly becomes an index reference. Downstream consumers that currently receive these results may be affected:

• build-image-index receives $(tasks.build-container.results.IMAGE_URL)@$(tasks.build-container.results.IMAGE_DIGEST) as its IMAGES array parameter. It expects "List of Image Manifests to be referenced by the Image Index." In dual mode, it would receive an index reference instead of a manifest reference, potentially creating a nested index.
• Tekton Chains uses IMAGE_DIGEST as the attestation subject. An index digest vs. a manifest digest may have different provenance semantics.
• The new IMAGES result (comma-separated child refs) has no consumer in any pipeline YAML — only pipeline READMEs are updated, not the pipeline definitions themselves.

Additionally, the buildah IMAGES result is a string type (comma-separated), while build-image-index expects IMAGES as an array type — these are different Tekton types.

Suggestion: Clarify the intended integration pattern. If build-image-index should handle individual variant refs in dual mode, pipeline YAMLs need updating. If build-image-index should receive the index directly, verify it handles index-of-index scenarios correctly. Consider coordinating with Tekton Chains and Enterprise Contract teams on index-digest provenance semantics.

2. Partial push failure leaves stale tags (medium — error-handling)

Files: all 5 buildah*.yaml task files (push step)

In dual mode, the push sequence involves 6 buildah push / buildah manifest push operations (gzip variant × 2 tags, zstd variant × 2 tags, index × 2 tags). If an early push succeeds but a later one fails, stale tags (e.g., TASKRUN_NAME-gzip) remain in the registry with no cleanup. While this pattern already exists in single mode (2 pushes), dual mode triples the failure surface.

Suggestion: This is an existing architectural pattern extended to dual mode, so it's not blocking. Consider documenting the partial-failure behavior or adding tag cleanup on error in a follow-up.

Informational notes

• CHANGELOG files (task/buildah*/CHANGELOG.md) are not updated. Each has an "Unreleased" section — consider adding an entry for the dual-compression feature.
• Pipeline YAML files are not modified, so users cannot configure COMPRESSION_FORMAT/FORCE_COMPRESSION via pipeline-level params without customization. This is expected since the defaults preserve existing behavior.
• No tests are added. The buildah tasks appear to lack in-repo unit tests, so this follows existing patterns, but the feature adds significant new code paths.
• The logic is duplicated across 5 task YAML files. Future refactoring into a shared script or the task-generator could reduce maintenance burden.

---

Labels: PR adds new buildah task feature (dual compression) with new parameters and results

Previous run (6)

Review — comment

PR: #3682 · Draft: yes
Author: Amanyd · Base: main
Refs: #1264, ADR 0070

Summary

This PR adds dual-compression support (gzip + zstd:chunked) to the five buildah task variants (buildah, buildah-oci-ta, buildah-oci-ta-min, buildah-remote, buildah-remote-oci-ta). Two new optional parameters are introduced:

• COMPRESSION_FORMAT — gzip (default) | zstd-chunked | dual
• FORCE_COMPRESSION — false (default) | true

In dual mode the push step pushes two single-manifest images (gzip and zstd:chunked variants), assembles a per-arch OCI index with gzip first for backward compatibility, and pushes the index. Signing, SBOM generation, and SBOM attachment are properly extended to iterate over all variants. The existing gzip-only flow is unchanged when the default parameters are used.

The approach is well-structured: input validation is robust (case guard + OCI format check), error handling is consistent with existing patterns, and the generate_oci_image_sbom() helper function reduces SBOM duplication within each variant. Parameters are correctly plumbed through stepTemplate env vars (COMPRESSION_FORMAT) and push-step env (FORCE_COMPRESSION), following the Tekton security rule against using $(params.*) directly in scripts.

Findings

1. IMAGES result separator mismatch — medium / correctness

All five task variants describe the new IMAGES result as "Newline-separated image manifest references", but the dual-mode code writes comma-separated values:

echo -n "${gzip_ref},${zstd_ref}" >"$(results.IMAGES.path)"

Affected files (same pattern in all):

• task/buildah/0.10/buildah.yaml
• task/buildah-oci-ta/0.10/buildah-oci-ta.yaml
• task/buildah-oci-ta-min/0.10/buildah-oci-ta-min.yaml
• task/buildah-remote/0.10/buildah-remote.yaml
• task/buildah-remote-oci-ta/0.10/buildah-remote-oci-ta.yaml

The IMAGES result exists specifically to feed Tekton Chains provenance with all individual manifest references. If Chains (or any downstream consumer) parses based on the documented newline separator, it would see the entire comma-separated string as a single malformed reference, silently breaking provenance for dual-compression builds.

Remediation: Either update the code to use newline separation:

printf '%s\n%s' "${gzip_ref}" "${zstd_ref}" >"$(results.IMAGES.path)"

Or, if comma separation is intentional (matching some Chains contract), update the descriptions in all five YAML files and corresponding READMEs to say "Comma-separated" instead of "Newline-separated."

2. No test coverage for dual mode — low / test-adequacy

This PR adds ~1,460 lines of new push/sign/SBOM logic across five task variants but includes no test changes. The dual-mode flow involves multiple sequential registry pushes, manifest index creation, cross-step communication via /shared/* files, and three-way SBOM generation — any of which could fail subtly. Even a basic integration test exercising COMPRESSION_FORMAT=dual with a local registry would catch regressions.

---

Labels: PR adds new Tekton task parameters and dual-compression build feature

Previous run (7)

Review — comment

PR: feat: add dual-compression (zstd:chunked) to buildah task
Status: Draft
Ref: #1264

Summary

This PR adds COMPRESSION_FORMAT (gzip | zstd-chunked | dual) and FORCE_COMPRESSION parameters to all five buildah task variants (buildah, buildah-oci-ta, buildah-oci-ta-min, buildah-remote, buildah-remote-oci-ta). In dual mode, the push step pushes separate gzip and zstd:chunked manifests, bundles them in a per-arch OCI index (gzip first for backward compatibility), signs all three artifacts (index + both children), generates per-variant SBOMs plus an index-level SBOM, and exposes the child manifest references via the new IMAGES result for Chains provenance.

The default remains gzip, so existing consumers are unaffected. The implementation correctly validates that dual requires BUILDAH_FORMAT=oci, uses a case-statement allowlist, and follows Tekton security best practices (params flow through stepTemplate.env / step-level env, never interpolated directly in scripts).

Findings

1. Code duplication across 5 task files — medium (style/maintenance)

Files: task/buildah*/0.10/buildah*.yaml (all 5 variants)

The dual-compression push logic (~120 new lines per file), signing loop, generate_oci_image_sbom helper function, SBOM-per-variant upload loop, and SBOM attestation loop are copy-pasted identically across all five task YAML files. While this follows the pre-existing pattern in the codebase, this PR roughly doubles the volume of duplicated script code. Any future bug fix or behavioral change to the dual path must be manually replicated across all five files, creating significant maintenance risk.

Remediation: Consider extracting the shared push/sign/SBOM shell logic into a common script (e.g., shipped in the konflux-build-cli image) or into a Tekton StepAction that all buildah task variants reference. This could be a follow-up.

2. No e2e test coverage for dual mode — medium (correctness)

File: e2e-tests/

The dual-compression workflow introduces substantial new complexity (per-variant push, index assembly, multi-SBOM generation, multi-image signing, IMAGES result for Chains). No e2e test scenarios are added in this PR. The existing test suite has no compression, zstd, or dual references.

Remediation: Add at least one e2e scenario that exercises COMPRESSION_FORMAT=dual and validates: (a) the per-arch index structure contains two manifests, (b) the IMAGES result lists both child refs, (c) SBOMs are attached to all three digests. This is expected before the PR leaves draft status.

3. SBOM pullspec inconsistency between dual and non-dual paths — low (correctness)

Files: All 5 task YAML files, prepare-sboms step

In non-dual mode, the SBOM is generated with $IMAGE_URL (read from the result path) as the pullspec:

generate_oci_image_sbom sbom.json "$IMAGE_DIGEST" "$IMAGE_URL"

In dual mode, it uses $IMAGE (the stepTemplate env var) directly:

generate_oci_image_sbom sbom-gzip.json "$gzip_digest" "$IMAGE"

Both resolve to the same value ($(params.IMAGE)), so this is functionally correct but stylistically inconsistent. Using the same source ($IMAGE_URL from result, or $IMAGE from env) in both paths would improve clarity.

Positive observations

• Backward compatibility: Both new params have safe defaults (gzip / false), making this a purely additive change.
• Input validation: Strict case allowlist for COMPRESSION_FORMAT plus explicit dual requires OCI guard.
• Tekton security: Both params are passed through env vars, never interpolated directly as $(params.*) in scripts — consistent with project rules.
• Signing completeness: In dual mode, all three artifacts (index, gzip child, zstd child) are signed and attested.
• SBOM completeness: Per-variant SBOMs plus an index-level SBOM are generated, attached, and signed.
• Chains integration: The IMAGES result follows the Chains convention for declaring multiple subject images.
• Documentation: All README files are updated with the new params and results.
• Index ordering: gzip is listed first in the per-arch index for backward compatibility with older Docker clients.

---

This is a draft PR. The observations above are intended to help guide the PR toward merge readiness.

---

Labels: PR modifies all buildah task variants to add dual-compression support and updates pipeline READMEs

Previous run (8)

Review of #3682 — feat: add dual-compression (zstd:chunked) to buildah task

Verdict: comment · 3 medium, 1 low findings · Draft PR

This PR adds COMPRESSION_FORMAT (gzip|zstd-chunked|dual) and FORCE_COMPRESSION parameters to all five buildah task variants. In dual mode it pushes gzip and zstd:chunked variants, bundles them in a per-arch OCI index (gzip first for backward compatibility), signs all three refs, generates per-variant SBOMs, and adds a new IMAGES result for Chains provenance. The default stays gzip, and all changes are backward-compatible.

The implementation follows the referenced ADR-0070 pattern well. The stepTemplate env wiring is correct (COMPRESSION_FORMAT in stepTemplate for all steps; FORCE_COMPRESSION in push step only), and the code structure across variants is consistent. Four concerns are worth addressing before this leaves draft status.

---

Findings

1 · No input validation for COMPRESSION_FORMAT — medium · correctness

Files: all 5 task YAML files (push step script)

The COMPRESSION_FORMAT parameter accepts any string, but only gzip, zstd-chunked, and dual are handled. An invalid value (e.g. "zstd" — a plausible typo) silently falls through to gzip behavior with no error or warning. Users would see a successful build but no zstd compression.

Remediation: Add an early validation guard at the top of the push step's script, e.g.:

case "${COMPRESSION_FORMAT}" in
  gzip|zstd-chunked|dual) ;;
  *)
    echo "ERROR: unsupported COMPRESSION_FORMAT '${COMPRESSION_FORMAT}'" >&2
    echo "Supported values: gzip, zstd-chunked, dual" >&2
    exit 1
    ;;
esac

2 · buildah manifest operations not wrapped in retry — medium · correctness

Files: all 5 task YAML files (dual-mode push logic)

All buildah push, cosign sign, and cosign attest calls use the retry wrapper to handle transient failures. However, in the dual code path, buildah manifest create, buildah manifest add (which fetches from the registry), and buildah manifest inspect run without retries:

buildah manifest create "$per_arch_index"
buildah manifest add "$per_arch_index" "docker://${gzip_ref}"
buildah manifest add "$per_arch_index" "docker://${zstd_ref}"
buildah manifest inspect "$per_arch_index" >/shared/per-arch-index-manifest.json

manifest add performs a network call to fetch the referenced manifest. A transient registry hiccup here would fail the entire task without retry.

Remediation: Wrap at least buildah manifest add calls with the retry utility, consistent with all other registry-interacting commands.

3 · Multi-platform + dual-mode interaction needs design validation — medium · correctness

Files: pipelines/docker-build-multi-platform-oci-ta/README.md, task/buildah-remote-oci-ta/0.10/buildah-remote-oci-ta.yaml

In multi-platform pipelines (docker-build-multi-platform-oci-ta, fbc-builder), each platform's buildah task produces a per-arch OCI index containing two manifests (gzip + zstd). The IMAGE_REF result — which points to this per-arch index — feeds into build-image-index:0.3:IMAGES. The build-image-index task then uses konflux-build-cli image build-image-index to combine these per-arch references into a multi-arch manifest.

This creates a nested index (index-of-indices). While valid per the OCI spec, it requires konflux-build-cli to correctly handle index entries, and downstream consumers (Chains provenance, EC policy, container runtimes) need to resolve them. If konflux-build-cli doesn't dereference the per-arch index with --all, the resulting multi-arch manifest would contain index entries instead of image manifests.

Remediation: Verify the konflux-build-cli behavior with nested index inputs. Consider documenting the dual+multi-platform interaction or gating dual mode to single-platform pipelines until multi-platform support is confirmed.

4 · No test coverage for new feature — low · test-adequacy

Files: (no test files modified)

This PR adds ~150 lines of new logic per variant (push, signing, SBOM generation, SBOM attachment) across 5 task files, but no tests accompany the change. While this is a draft PR, at minimum a manual test plan or e2e test skeleton would help validate the feature before review.

---

What looks good

• Backward compatibility: The gzip default means zero impact on existing pipelines.
• Correct env wiring: COMPRESSION_FORMAT is in stepTemplate (available to all steps), FORCE_COMPRESSION correctly scoped to the push step only — matches the Tekton best practice in .cursor/rules/tekton.mdc of using env vars rather than $(params.*) directly in scripts.
• Proper error handling: Early exit if COMPRESSION_FORMAT=dual without BUILDAH_FORMAT=oci. All push operations have retry and error reporting.
• Signing completeness: Dual mode correctly signs all three variants (index + gzip child + zstd child) with consistent cosign invocations.
• SBOM coverage: Separate SBOMs generated per variant with the generate_oci_image_sbom helper function reducing duplication within each task.
• Documentation: READMEs updated for all affected pipelines and tasks.

Previous run (9)

Review — comment

PR: #3682 — feat: add dual-compression (zstd:chunked) to buildah task
Status: Draft
Scope: Adds COMPRESSION_FORMAT (gzip|zstd-chunked|dual) and FORCE_COMPRESSION params to all 5 buildah task variants (buildah, buildah-oci-ta, buildah-oci-ta-min, buildah-remote, buildah-remote-oci-ta). In dual mode, pushes gzip and zstd:chunked variants into a per-arch OCI index, with signing and SBOM generation for each variant.

This is a well-structured feature that aligns with issue #1264 and the referenced ADR-0070. The implementation correctly handles the push/sign/SBOM lifecycle for both compression variants, follows existing Tekton security patterns (params passed via env vars, not used directly in scripts), and maintains backward compatibility (default remains gzip).

Findings

1. Missing input validation for COMPRESSION_FORMAT — medium / correctness

File: all 5 task YAML files (push step script)

The script checks for dual and zstd-chunked but has no explicit validation that the parameter value is one of the three accepted values. An invalid value (e.g., "zstd" without -chunked, "DUAL" with wrong case, or a typo like "gzp") silently falls through to gzip-like behavior with no warning.

Remediation: Add early validation at the top of the push step:

case "${COMPRESSION_FORMAT}" in
  gzip|zstd-chunked|dual) ;;
  *) echo "ERROR: invalid COMPRESSION_FORMAT '${COMPRESSION_FORMAT}' (expected gzip, zstd-chunked, or dual)" >&2; exit 1 ;;
esac

2. buildah manifest add not wrapped in retry — medium / correctness

File: all 5 task YAML files (push step, dual mode)
Lines: buildah manifest add "$per_arch_index" "docker://${gzip_ref}" and the zstd equivalent

All buildah push and buildah manifest push calls are correctly wrapped in retry, but buildah manifest add with a docker:// reference performs a registry pull and is susceptible to transient network failures. In a multi-step push flow where this is the only unguarded registry operation, it becomes the most likely point of intermittent failure.

Remediation: Wrap both buildah manifest add calls in retry:

retry buildah manifest add "$per_arch_index" "docker://${gzip_ref}"
retry buildah manifest add "$per_arch_index" "docker://${zstd_ref}"

3. --force-compression not applied to gzip variant in dual mode — medium / correctness

File: all 5 task YAML files (push step, dual mode gzip push)

When FORCE_COMPRESSION=true and COMPRESSION_FORMAT=dual, the zstd variant correctly receives --force-compression, but the gzip variant does not. If a base image contains layers with non-gzip compression (e.g., zstd), the gzip variant will retain those layers as-is, producing a manifest with mixed compression formats. This contradicts the user's intent when setting FORCE_COMPRESSION=true.

The gzip push currently hardcodes:

buildah push --format=oci --compression-format gzip ...

Without --force-compression, the --compression-format gzip flag only affects newly-created layers; base-image layers keep their original compression.

Remediation: Apply --force-compression conditionally to the gzip variant as well:

gzip_push_args=(--format=oci --retry "$buildah_retries" --tls-verify="$TLSVERIFY" --compression-format gzip --digestfile /tmp/gzip-digest)
if [ "${FORCE_COMPRESSION}" = "true" ]; then
  gzip_push_args+=(--force-compression)
fi
retry buildah push "${gzip_push_args[@]}" "$IMAGE" "docker://${gzip_tag}"

Notes (non-blocking)

• The same ~150 lines of dual-compression logic is replicated across all 5 task YAML files. This follows the existing repo pattern but significantly increases the surface area for divergence. Future refactoring into a shared script (injected via the task-runner image) would reduce this.
• Intermediate variant tags (${TASKRUN_NAME}-gzip, ${TASKRUN_NAME}-zstd) are pushed to the registry but never cleaned up. These are referenced by digest in the index so the tags are redundant after push; registry tag retention policies should handle cleanup, but explicit deletion would be cleaner.
• The IMAGES result in non-dual mode includes the image tag in the reference (repo:tag@sha256:...), while dual mode omits it (repo@sha256:...). Both are valid OCI references, but consumers parsing the format should be aware of the difference.

---

Labels: PR adds new Tekton task parameters and dual-compression build feature

Previous run (10)

Review — comment

PR: #3682 — feat: add dual-compression (zstd:chunked) to buildah task
Status: Draft
Author: Amanyd
Ref: #1264

Summary

This PR adds dual-compression support across five buildah task variants (buildah, buildah-oci-ta, buildah-oci-ta-min, buildah-remote, buildah-remote-oci-ta), introducing two new optional parameters (COMPRESSION_FORMAT, FORCE_COMPRESSION) and a new IMAGES result. In dual mode, the task pushes both gzip and zstd:chunked variants bundled in a per-arch OCI image index (gzip first for backward compatibility), generates separate SBOMs per variant, and signs each variant and index independently.

The overall design is architecturally sound — fail-fast validation for OCI format, correct per-arch index construction, comprehensive signing and SBOM generation per variant, and proper Tekton result wiring. The backward-compatible default (gzip) and the gzip-first ordering invariant are well-thought-out.

Findings

1. SBOM image-pullspec inconsistency in buildah-oci-ta-min — medium

File: task/buildah-oci-ta-min/0.10/buildah-oci-ta-min.yaml (lines 1115–1121)

In buildah-oci-ta-min, the dual-mode SBOM generation uses $image_repo (${IMAGE%:*}, the repo without the tag) as the third argument to generate_oci_image_sbom:

image_repo="${IMAGE%:*}"
generate_oci_image_sbom sbom-gzip.json "$gzip_digest" "$image_repo"
generate_oci_image_sbom sbom-zstd.json "$zstd_digest" "$image_repo"

All other four variants use $IMAGE (full repo:tag) at the equivalent location:

generate_oci_image_sbom sbom-gzip.json "$gzip_digest" "$IMAGE"
generate_oci_image_sbom sbom-zstd.json "$zstd_digest" "$IMAGE"

This means --image-pullspec in the generated SBOM will differ between buildah-oci-ta-min (repo only) and all other variants (repo:tag) for the same build. Downstream SBOM consumers that key on the pullspec may see inconsistent identifiers.

Remediation: Use "$IMAGE" in buildah-oci-ta-min to match the other variants, or intentionally use "$image_repo" consistently across all five files if the tag-less form is preferred for child manifests (and document the rationale).

2. No input validation for COMPRESSION_FORMAT values — medium

File: All five task YAML files

The COMPRESSION_FORMAT parameter accepts any string, but only gzip, zstd-chunked, and dual are handled. An invalid value (e.g., "zstd" — a plausible typo of "zstd-chunked") silently falls through to gzip behavior without any warning. With set -euo pipefail, this won't cause an error — it simply won't do what the user intended.

Remediation: Add early validation before the compression logic:

case "${COMPRESSION_FORMAT}" in
  gzip|zstd-chunked|dual) ;;
  *) echo "ERROR: Unknown COMPRESSION_FORMAT '${COMPRESSION_FORMAT}'. Must be gzip, zstd-chunked, or dual." >&2; exit 1 ;;
esac

3. IMAGES result trailing newline inconsistency — low

File: All five task YAML files (push step)

In dual mode, echo is used to write refs (adding trailing newlines):

{ echo "${gzip_ref}"; echo "${zstd_ref}"; } >"$(results.IMAGES.path)"

In single mode, echo -n + cat is used (no trailing newline):

{ echo -n "${IMAGE}@"; cat "/var/workdir/image-digest"; } >"$(results.IMAGES.path)"

If downstream consumers parse this result with while read -r line, the missing trailing newline in single mode can cause the last (only) line to be silently dropped unless the read loop handles EOF. Consider normalizing the format.

4. Orphaned gzip/zstd variant tags — low

File: All five task YAML files (push step, dual mode)

In dual mode, intermediate tags ${TASKRUN_NAME}-gzip and ${TASKRUN_NAME}-zstd are pushed to the registry but never cleaned up. In high-volume CI environments, these accumulate as storage overhead. The PR description acknowledges Tekton result size constraints for large matrix builds, but registry tag accumulation is a separate concern.

Remediation: Either document this as expected behavior (tags are useful for debugging) or add a cleanup step that deletes the intermediate tags after the per-arch index is pushed.

5. ATT_SBOM_TYPE scope placement inconsistency — low

File: task/buildah-oci-ta-min/0.10/buildah-oci-ta-min.yaml (line 1190)

In buildah-oci-ta-min, the ATT_SBOM_TYPE variable derivation was moved outside the signing conditional block (before the SBOM push loop), while all other variants keep it inside the signing conditional. This is functionally harmless but adds an unnecessary structural difference between task variants that share otherwise identical logic.

---

Labels: PR adds new compression format feature to buildah build tasks

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 7:03 AM UTC · Completed 7:12 AM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 7:18 AM UTC · Completed 7:27 AM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 8:00 AM UTC · Completed 8:10 AM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 10:31 AM UTC · Completed 10:39 AM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 3:43 PM UTC · Completed 3:58 PM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 5:08 PM UTC · Ended 5:15 PM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 5:27 PM UTC · Completed 5:35 PM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 6:00 PM UTC · Completed 6:13 PM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 7:17 PM UTC · Completed 7:26 PM UTC
Commit: 14477fe · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 8:28 PM UTC · Completed 8:39 PM UTC
Commit: 14477fe · View workflow run →

[Amanyd]

Ready to review