incluster-comp-pr-merged: use registry cache instead of GHA cache#89
Conversation
📝 WalkthroughWalkthroughThe ChangesDocker Build Cache
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/incluster-comp-pr-merged.yaml (1)
180-181: 🚀 Performance & Scalability | 🔵 TrivialAdd retention and storage monitoring for the registry cache.
mode=maxstores intermediate layers in Quay; add a cleanup/retention policy and alerting so repeated builds do not accumulate unbounded cache storage.🤖 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/incluster-comp-pr-merged.yaml around lines 180 - 181, Update the workflow’s registry cache configuration for cache-to in the build step to add an appropriate Quay retention or cleanup policy and storage monitoring/alerting for the buildcache reference, while preserving cache reuse and mode=max behavior.
🤖 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/incluster-comp-pr-merged.yaml:
- Around line 180-181: Remove the actions: write entry from the job permissions
block governing the build steps in the workflow, while preserving registry
authentication and all existing read permissions. The cache-related build
configuration using cache-from and cache-to does not require GitHub Actions
write access.
---
Nitpick comments:
In @.github/workflows/incluster-comp-pr-merged.yaml:
- Around line 180-181: Update the workflow’s registry cache configuration for
cache-to in the build step to add an appropriate Quay retention or cleanup
policy and storage monitoring/alerting for the buildcache reference, while
preserving cache reuse and mode=max behavior.
🪄 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
Run ID: e34caeba-5660-47c6-b7cb-9bd63437bc68
📒 Files selected for processing (1)
.github/workflows/incluster-comp-pr-merged.yaml
|
Summary:
|
1 similar comment
|
Summary:
|
Remove actions: write from docker-build job permissions. It was added specifically to support the type=gha cache backend's write requirement (commit ad4904d); now that this job uses type=registry cache exclusively, it no longer touches GitHub's Actions Cache service at all, so the permission is unnecessary. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Yuval Levy <yuvalle@armosec.io>
Alternative, simpler fix for 'error writing layer blob: failed to reserve cache' (seen e.g. on kubevuln's pr-merged run: https://github.com/kubescape/kubevuln/actions/runs/29737569926/job/88346893168). The failure is caused by GitHub issuing read-only Actions-cache tokens to pull_request_target-triggered runs that resolve to the default branch (policy change 2026-06-26, see https://github.blog/changelog/2026-06-26-read-only-actions-cache-for-untrusted-triggers/ and docker/build-push-action#1571 (comment)). kubevuln's (and every other consumer's) pr-merged.yaml triggers on pull_request_target: types: [closed], so once a PR merges into main, cache-to: type=gha's first blob-write attempt fails with exactly "failed to reserve cache" -- independent of job/matrix structure. Switching cache-from/cache-to to type=registry avoids this mechanism entirely: cache layers become ordinary content-addressed OCI blobs pushed to Quay (already authenticated via the existing Login to Quay step) instead of going through GitHub's actions-cache API, so the trigger-trust restriction can't affect it. All 6 confirmed consumers of this reusable workflow (synchronizer, operator, prometheus-exporter, kubevuln, storage, http-request) build Go binaries with a "--platform=$BUILDPLATFORM" cross-compile pattern in their Dockerfiles and no RUN steps requiring target-arch execution, so this keeps the original single docker-build job, single multi-platform build-push-action call, and QEMU setup entirely unchanged -- only the cache backend changes. Also removes the now-unnecessary actions: write permission (added in a recent main commit specifically to support type=gha cache writes; no longer needed since this job doesn't touch GitHub's Actions Cache Service at all). Cache is stored under "${IMAGE_NAME}:buildcache" in Quay. Unlike GHA cache, it isn't subject to GitHub's 10GB/repo eviction -- worth monitoring Quay storage/retention for this tag over time. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Yuval Levy <yuvalle@armosec.io>
|
Summary:
|
34541e0 to
f1001ba
Compare
|
Summary:
|
1 similar comment
|
Summary:
|
|
Summary:
|
Root cause
error writing layer blob: failed to reserve cache— GitHub started issuing read-only Actions-cache tokens (2026-06-26) to runs that resolve to the default branch, for any triggering event not on a small trusted allowlist (push,workflow_dispatch,repository_dispatch,delete,registry_package,page_build,schedule).pull_request_targetisn't on that list.This workflow's callers (kubevuln and all other consumers) trigger on
pull_request_target: types: [closed]— once a PR merges,GITHUB_REFresolves tomain(the default branch), so the run gets a read-only cache token, andcache-to: type=gha's first blob-write fails with exactly this error. This is independent of build platform count, job structure, or cache scope.Confirmed via GitHub Support in docker/build-push-action#1571: docker/build-push-action#1571 (comment)
Fix
Swap
cache-from/cache-tofromtype=ghatotype=registry,ref=${IMAGE_NAME}:buildcache. Registry cache authenticates via the existing Quay login and never touches GitHub's Actions Cache Service, so the trigger-trust restriction can't affect it.Chose this over fixing the trigger itself (e.g. swapping to
pushon the target branch, as GitHub Support suggests) because maintainers sometimes push directly tomainand do not want that to trigger a release — a naivepush-based trigger would break that expectation across all 6 consumers. Registry cache fixes the actual bug without touching any consumer's trigger.Also removes the
actions: writepermission from thedocker-buildjob — it was added specifically to supporttype=ghacache writes and is no longer needed.Test plan
pr-mergedon a consumer repo (e.g. kubevuln) pointed at this branch and confirm no "failed to reserve cache" error