fix(ci): pin Trivy platform when scanning release digests#191
Merged
Conversation
build-release-* pushes by digest and buildx wraps the single-platform image
in an OCI index (it attaches a provenance attestation manifest). Trivy
resolves the digest remotely but, for an index ref, selects the child
matching the runner's platform — so on the amd64 runner the arm64 leg fails
100% with "no child with platform linux/amd64 in index".
That reds image-scan-release, which fails the reusable ci workflow, which
release-please needs — so it blocks every release (fails safe: no tag, no
half-published release, but nothing ships).
Pin TRIVY_PLATFORM=linux/${matrix.arch} on both Trivy steps so each leg
selects the correct child from the index, and correct the stale comment that
claimed a push-by-digest ref carries no platform-selection step.
Can only be fully validated by a main run (GitHub Actions behavior); actionlint clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughUpdates the CI workflow's Trivy image scanning steps for release images to explicitly set ChangesTrivy Platform Pinning
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/ci.yml (1)
667-668: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider hoisting
TRIVY_PLATFORMto job-levelenv:to avoid duplication.The same comment and
TRIVY_PLATFORM: linux/${{ matrix.arch }}assignment is repeated on both Trivy steps. Since it's derived solely frommatrix.arch, defining it once under the job'senv:block would remove the duplication and keep both steps in sync automatically.Also applies to: 689-690
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml around lines 667 - 668, The TRIVY_PLATFORM assignment is duplicated across the Trivy steps, so move it to the job-level env for the workflow job that contains the Trivy scan steps. Use the matrix.arch-derived value once in the job env block so both Trivy steps inherit it automatically, and remove the repeated TRIVY_PLATFORM entries from the individual steps.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 661-663: The Docker login step in the CI workflow is interpolating
`secrets.GITHUB_TOKEN` and `github.actor` directly inside the `run` shell block,
which should be moved to step-level `env:` variables instead. Update the
workflow step that runs `docker login` to define `GH_TOKEN` and `GH_ACTOR` in
`env:`, then reference those variables in the `run:` command. Keep the registry
reference as-is and ensure the login command uses the env vars rather than
template expressions in the shell block.
---
Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 667-668: The TRIVY_PLATFORM assignment is duplicated across the
Trivy steps, so move it to the job-level env for the workflow job that contains
the Trivy scan steps. Use the matrix.arch-derived value once in the job env
block so both Trivy steps inherit it automatically, and remove the repeated
TRIVY_PLATFORM entries from the individual steps.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 9416dd38-de3c-41b2-8dd5-f3c39baef48c
📒 Files selected for processing (1)
.github/workflows/ci.yml
Comment on lines
661
to
663
| run: | | ||
| echo "${{ secrets.GITHUB_TOKEN }}" | docker login ${{ env.REGISTRY }} -u ${{ github.actor }} --password-stdin | ||
|
|
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the workflow around the referenced lines
sed -n '640,675p' .github/workflows/ci.yml
# Locate the login step and any nearby env usage
rg -n "docker login|GITHUB_TOKEN|github.actor|REGISTRY" .github/workflows/ci.ymlRepository: ConfigButler/gitops-reverser
Length of output: 3920
Hoist the login arguments into env:
Use step env vars for secrets.GITHUB_TOKEN and github.actor, then reference $GH_TOKEN / $GH_ACTOR in run: to avoid the template-injection sink in this shell block.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 662-662: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml around lines 661 - 663, The Docker login step in
the CI workflow is interpolating `secrets.GITHUB_TOKEN` and `github.actor`
directly inside the `run` shell block, which should be moved to step-level
`env:` variables instead. Update the workflow step that runs `docker login` to
define `GH_TOKEN` and `GH_ACTOR` in `env:`, then reference those variables in
the `run:` command. Keep the registry reference as-is and ensure the login
command uses the env vars rather than template expressions in the shell block.
Source: Linters/SAST tools
Bring the plan doc to the current handover state: PR 1 merged via #190 (2b3a949), PRs 2-5 remaining with current-tree anchors, and the §4 cross-arch claim corrected to match the TRIVY_PLATFORM fix in this PR — push-by-digest builds are OCI indexes, so Trivy must be told which child to scan. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sunib
enabled auto-merge (squash)
July 3, 2026 08:50
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This was referenced Jul 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The first
mainrun of the plan-PR-1 pipeline (#190) exposed a 100%, release-blocking failure:Scan release image (arm64)fails withRoot cause
build-release-*builds withpush-by-digest=true, and buildx wraps the single-platform image in an OCI index (it attaches a provenance attestation manifest). Trivy resolves the digest remotely but, for an index ref, selects the child matching the runner's platform. On theubuntu-latest(amd64) runner:linux/amd64child);linux/amd64child.This falsifies the earlier assumption that a push-by-digest ref "carries no platform-selection step".
Impact
image-scan-releasefailing → the reusableciworkflow fails →release-please(needs: ci) never runs → no tag, no release, nothing published. It fails safe (no orphaned tag / half-release), but it means a release cannot currently be cut until this lands.Fix
Pin
TRIVY_PLATFORM=linux/${{ matrix.arch }}on both Trivy steps in theimage-scan-releasematrix so each leg selects the correct child from the index (amd64 is now correct-by-construction, not by runner coincidence). Also corrects the stale comment.Env var is used rather than an action input so it targets the
trivybinary directly, independent of the trivy-action version.Validation
actionlintclean; YAML parses.mainrun after merge — watch thatScan release image (arm64)goes green.🤖 Generated with Claude Code
Summary by CodeRabbit
Also in this PR: syncs
docs/design/release-image-reuse-plan.mdto the current handover state (PR 1 merged via #190, PRs 2–5 remaining, this arm64 blocker recorded, §4 cross-arch claim corrected to match the fix).