feat: ec pipeline supports large snapshot specs by kasemAlem · Pull Request #3124 · conforma/cli

kasemAlem · 2026-02-25T12:05:59Z

Modify script to enable snapshots with large specs

STONEINTG-1470

qodo-code-review · 2026-02-25T12:06:11Z

Review Summary by Qodo

EC pipeline supports large snapshot specs via custom resources

✨ Enhancement

Walkthroughs

Description

• Support custom resource names as snapshot input in EC pipeline
• Fetch snapshot from Kubernetes cluster when valid CR name provided
• Validate CR names against Kubernetes DNS label rules (≤63 chars, lowercase)
• Maintain backward compatibility with file path and literal content handling

Diagram

flowchart LR
  A["SNAPSHOT input"] --> B{"Is file path?"}
  B -->|Yes| C["Copy file to working snapshot"]
  B -->|No| D{"Valid CR name?"}
  D -->|Yes| E["Fetch CR from cluster with kubectl"]
  D -->|No| F["Treat as literal content"]
  E --> G["Store JSON in working snapshot"]
  C --> H["Process with jq"]
  F --> H
  G --> H

File Changes

1. hack/reduce-snapshot.sh ✨ Enhancement +16/-5

Add custom resource name support for snapshot input

• Enhanced SNAPSHOT parameter to accept Kubernetes custom resource names in addition to file paths
• Added validation logic to check if SNAPSHOT matches Kubernetes DNS label rules (lowercase, digits,
 hyphens, max 63 chars)
• Implemented kubectl get command to fetch custom resource JSON when valid CR name is detected
• Updated documentation comments to clarify SNAPSHOT parameter behavior and new CR name support
• Maintained backward compatibility with existing file path and literal content handling

hack/reduce-snapshot.sh

qodo-code-review · 2026-02-25T12:06:12Z

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. kubectl get args mismatch 🐞 Bug ✓ Correctness

Description

The new cluster-fetch path assumes CUSTOM_RESOURCE is a resource kind and SNAPSHOT is the name, but
existing task docs/usage pass CUSTOM_RESOURCE as kind/name (e.g. pr/somepipeline). When SNAPSHOT
looks like a CR name, this will call kubectl with an extra positional argument and fail.

Code

hack/reduce-snapshot.sh[R47-51]

+elif [[ ${#SNAPSHOT} -le 63 && "$SNAPSHOT" =~ $VALID_CR_NAME_PATTERN ]]; then
+  CR_NAMESPACE_ARG=()
+  [[ -n "${CUSTOM_RESOURCE_NAMESPACE:-}" ]] && CR_NAMESPACE_ARG=(-n "$CUSTOM_RESOURCE_NAMESPACE")
+  kubectl get "$CUSTOM_RESOURCE" "$SNAPSHOT" "${CR_NAMESPACE_ARG[@]}" -o json > "$WORKING_SNAPSHOT" || \
+    { echo "Failed to get custom resource: $SNAPSHOT"; exit 1; }

Evidence
The new code calls kubectl get "$CUSTOM_RESOURCE" "$SNAPSHOT" ..., which only works if
CUSTOM_RESOURCE is a kind and SNAPSHOT is the name. However, the Tekton task parameter and README
explicitly define CUSTOM_RESOURCE as “Name, including kind” (kind/name), and the script’s existing
single-component logic also calls kubectl get "$CUSTOM_RESOURCE" without supplying a separate
name—confirming it expects kind/name in CUSTOM_RESOURCE.
hack/reduce-snapshot.sh[47-51]
tasks/verify-enterprise-contract/0.1/README.md[44-46]
tasks/verify-enterprise-contract/0.1/verify-enterprise-contract.yaml[138-143]
tasks/verify-enterprise-contract/0.1/verify-enterprise-contract.yaml[221-229]
hack/reduce-snapshot.sh[66-69]

Agent prompt

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

### Issue description
`reduce-snapshot.sh` now tries to interpret `SNAPSHOT` as a Kubernetes CR name and fetch it using `kubectl get &quot;$CUSTOM_RESOURCE&quot; &quot;$SNAPSHOT&quot; ...`. This conflicts with existing usage where `CUSTOM_RESOURCE` is passed as `kind/name` (e.g. `pr/somepipeline`), causing `kubectl get` to be invoked with invalid positional arguments.

### Issue Context
- Tekton tasks in this repo document and pass `CUSTOM_RESOURCE` as `kind/name`.
- The script’s single-component mode also expects `CUSTOM_RESOURCE` to already include the name.

### Fix Focus Areas
- hack/reduce-snapshot.sh[42-54]
- tasks/verify-enterprise-contract/0.1/verify-enterprise-contract.yaml[214-234]
- tasks/verify-enterprise-contract/0.1/README.md[44-46]

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

2. Reduction fails on CR JSON 🐞 Bug ✓ Correctness

Description

When the new path fetches a Snapshot CR via kubectl, the JSON will commonly contain the snapshot
spec under .spec, but the reduction logic assumes .components exists at the root. In
SINGLE_COMPONENT mode this can error (cannot iterate over null) or fail to reduce.

Code

hack/reduce-snapshot.sh[R50-51]

+  kubectl get "$CUSTOM_RESOURCE" "$SNAPSHOT" "${CR_NAMESPACE_ARG[@]}" -o json > "$WORKING_SNAPSHOT" || \
+    { echo "Failed to get custom resource: $SNAPSHOT"; exit 1; }

Evidence
The new code writes the full kubectl JSON output to WORKING_SNAPSHOT. In this repo’s Kubernetes
snapshot CRs, the snapshot spec is wrapped under .spec (not at the root). The reduction logic
later deletes from .components[] and counts .components[], which will not work when components
live under .spec.components.
hack/reduce-snapshot.sh[50-51]
acceptance/kubernetes/stub/stub.go[112-125]
internal/applicationsnapshot/input.go[185-197]
hack/reduce-snapshot.sh[76-81]

Agent prompt

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

### Issue description
When `SNAPSHOT` is fetched from the cluster, the resulting JSON is typically a Kubernetes CR with the snapshot spec nested at `.spec`. The script’s SINGLE_COMPONENT reduction currently assumes `.components` is at the root, which breaks for CR-shaped input.

### Issue Context
`internal/applicationsnapshot.readSnapshotSource` supports both bare SnapshotSpec and CR-shaped `{spec: ...}` inputs, and tests/stubs in this repo create Snapshot CRs with a `spec` wrapper.

### Fix Focus Areas
- hack/reduce-snapshot.sh[47-54]
- hack/reduce-snapshot.sh[76-88]

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

3. CR-name heuristic too strict 🐞 Bug ⛯ Reliability

Description

The script only treats SNAPSHOT as a CR name when it is a DNS-label (≤63 chars) with no namespace
component, but repo code/tests support snapshot refs like namespace/name. This can cause
namespace/name inputs to be treated as literal JSON and fail validation with a confusing “JSON is
invalid” error.

Code

hack/reduce-snapshot.sh[R43-48]

+# Kubernetes resource names: DNS label, max 63 chars, [a-z0-9]([-a-z0-9]*[a-z0-9])?
+VALID_CR_NAME_PATTERN='^[a-z0-9]([-a-z0-9]*[a-z0-9])?$'
if [[ -f "$SNAPSHOT" ]]; then
  cp "$SNAPSHOT" "$WORKING_SNAPSHOT"
+elif [[ ${#SNAPSHOT} -le 63 && "$SNAPSHOT" =~ $VALID_CR_NAME_PATTERN ]]; then
+  CR_NAMESPACE_ARG=()

Evidence

The new heuristic explicitly matches only DNS-label names. Meanwhile the CLI’s snapshot reference
format supports an optional namespace prefix ([namespace/]name) and unit tests exercise
namespace/name as valid; these refs won’t match the heuristic and will fall through to the
‘literal content’ path.

hack/reduce-snapshot.sh[43-48]
internal/applicationsnapshot/input_test.go[79-86]
internal/kubernetes/client.go[132-136]

Agent prompt

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

### Issue description
`reduce-snapshot.sh` decides whether to fetch a resource from cluster based on a strict DNS-label regex and length, which excludes common snapshot ref formats like `namespace/name` supported elsewhere in the repo.

### Issue Context
The Go CLI supports snapshot references in the form `[namespace/]name`.

### Fix Focus Areas
- hack/reduce-snapshot.sh[43-54]
- internal/kubernetes/client.go[132-136]
- internal/applicationsnapshot/input_test.go[79-86]

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

ⓘ The new review experience is currently in Beta. Learn more

hack/reduce-snapshot.sh

kasemAlem · 2026-02-25T19:39:57Z

/retest

kasemAlem · 2026-02-25T19:42:51Z

/review

qodo-code-review · 2026-02-25T19:43:14Z

PR Reviewer Guide 🔍

(Review updated until commit `af824d7`)

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review Namespace The Snapshot fetch path relies on the current `kubectl` context namespace, but the comments indicate “current/pipeline namespace only” and there is also a `CUSTOM_RESOURCE_NAMESPACE` variable mentioned. Validate this always targets the intended namespace (e.g., by passing `-n` explicitly) to avoid fetching the wrong Snapshot in multi-namespace clusters/CI. elif [[ ${#SNAPSHOT} -le 63 && "$SNAPSHOT" =~ $VALID_CR_NAME_PATTERN ]]; then # Fetch Snapshot from the current namespace (Tekton pipeline namespace only). kubectl get snapshot/"${SNAPSHOT}" -o json \| jq .spec > "$WORKING_SNAPSHOT" \|\| \ { echo "Failed to get Snapshot: $SNAPSHOT"; exit 1; } Data Shape The fetch path writes only `.spec` to the working file, whereas the file-path branch copies the whole file as-is. Confirm downstream `jq` logic expects a `SnapshotSpec` consistently (not a full Snapshot object), and that local file inputs are in the same shape, otherwise behavior will diverge between file vs cluster-fetched inputs. if [[ -f "$SNAPSHOT" ]]; then cp "$SNAPSHOT" "$WORKING_SNAPSHOT" elif [[ ${#SNAPSHOT} -le 63 && "$SNAPSHOT" =~ $VALID_CR_NAME_PATTERN ]]; then # Fetch Snapshot from the current namespace (Tekton pipeline namespace only). kubectl get snapshot/"${SNAPSHOT}" -o json \| jq .spec > "$WORKING_SNAPSHOT" \|\| \ { echo "Failed to get Snapshot: $SNAPSHOT"; exit 1; } else printf "%s" "$SNAPSHOT" > "$WORKING_SNAPSHOT" fi Ambiguous Input Any non-file SNAPSHOT value that is <=63 chars and matches the DNS-label regex will be treated as a cluster resource name. This can accidentally trigger `kubectl get snapshot/...` for short literal JSON or other content. Consider an explicit mode/flag (or a `snapshot/<name>` prefix) to disambiguate and make failures more predictable. # Kubernetes resource names: DNS label, max 63 chars, [a-z0-9]([-a-z0-9][a-z0-9])? VALID_CR_NAME_PATTERN='^[a-z0-9]([-a-z0-9][a-z0-9])?$' if [[ -f "$SNAPSHOT" ]]; then cp "$SNAPSHOT" "$WORKING_SNAPSHOT" elif [[ ${#SNAPSHOT} -le 63 && "$SNAPSHOT" =~ $VALID_CR_NAME_PATTERN ]]; then # Fetch Snapshot from the current namespace (Tekton pipeline namespace only). kubectl get snapshot/"${SNAPSHOT}" -o json \| jq .spec > "$WORKING_SNAPSHOT" \|\| \ { echo "Failed to get Snapshot: $SNAPSHOT"; exit 1; } else printf "%s" "$SNAPSHOT" > "$WORKING_SNAPSHOT"

hack/reduce-snapshot.sh

kasemAlem · 2026-02-26T16:48:05Z

/review

qodo-code-review · 2026-02-26T16:48:30Z

Persistent review updated to latest commit cd9a62b

kasemAlem · 2026-02-26T17:16:09Z

/review

qodo-code-review · 2026-02-26T17:16:29Z

Persistent review updated to latest commit 941d23c

kasemAlem · 2026-02-26T17:22:03Z

/review

qodo-code-review · 2026-02-26T17:22:27Z

Persistent review updated to latest commit af824d7

When SNAPSHOT is not a file path, treat it as a custom resource name if it matches Kubernetes DNS label rules (lowercase, digits, hyphens, ≤63 chars). In that case fetch the resource with kubectl get and use its JSON as the working snapshot; otherwise keep the previous behavior of writing SNAPSHOT literally to the working file. Signed-off-by: Kasem Alem <kalem@redhat.com>

kasemAlem · 2026-02-26T17:34:08Z

We intentionally do not pass -n so the fetch uses the current kubectl context. In Tekton the task runs in the pipeline namespace; locally the context is the workspace. The script comments have been updated to document this so the intended namespace (context namespace) is explicit.

github-actions bot added the size: XS label Feb 25, 2026

qodo-code-review bot reviewed Feb 25, 2026

View reviewed changes

hack/reduce-snapshot.sh Outdated Show resolved Hide resolved

hack/reduce-snapshot.sh Outdated Show resolved Hide resolved

dirgim reviewed Feb 25, 2026

View reviewed changes

hack/reduce-snapshot.sh Outdated Show resolved Hide resolved

kasemAlem force-pushed the STONEINTG-1470 branch from a857a1e to d015248 Compare February 25, 2026 19:21

kasemAlem requested a review from dirgim February 25, 2026 19:41

qodo-code-review bot added the Review effort 2/5 label Feb 25, 2026

dirgim reviewed Feb 26, 2026

View reviewed changes

hack/reduce-snapshot.sh Outdated Show resolved Hide resolved

kasemAlem force-pushed the STONEINTG-1470 branch from d015248 to cd9a62b Compare February 26, 2026 16:47

kasemAlem force-pushed the STONEINTG-1470 branch from cd9a62b to 941d23c Compare February 26, 2026 17:15

kasemAlem force-pushed the STONEINTG-1470 branch from 941d23c to af824d7 Compare February 26, 2026 17:21

kasemAlem force-pushed the STONEINTG-1470 branch from af824d7 to e89f999 Compare February 26, 2026 17:33

Conversation

kasemAlem commented Feb 25, 2026

Uh oh!

qodo-code-review bot commented Feb 25, 2026

Review Summary by Qodo

Walkthroughs

File Changes

Uh oh!

qodo-code-review bot commented Feb 25, 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!

kasemAlem commented Feb 25, 2026

Uh oh!

kasemAlem commented Feb 25, 2026

Uh oh!

qodo-code-review bot commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Reviewer Guide 🔍

(Review updated until commit af824d7)

Uh oh!

Uh oh!

kasemAlem commented Feb 26, 2026

Uh oh!

qodo-code-review bot commented Feb 26, 2026

Uh oh!

kasemAlem commented Feb 26, 2026

Uh oh!

qodo-code-review bot commented Feb 26, 2026

Uh oh!

kasemAlem commented Feb 26, 2026

Uh oh!

qodo-code-review bot commented Feb 26, 2026

Uh oh!

kasemAlem commented Feb 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

qodo-code-review bot commented Feb 25, 2026 •

edited

Loading

qodo-code-review bot commented Feb 25, 2026 •

edited

Loading

(Review updated until commit `af824d7`)