fix(build): read --cache-from from ghcr :latest so PR builds warm-start - #2855
Conversation
PR #2711 switched PR builds to push only :pr-<N>-<sha> tags (PUBLISH_FLOATING=0) to stop concurrent-push 409 conflicts, but left --cache-from pointing at $(REGISTRY)/<img>:latest. PR builds set REGISTRY to the per-CI registry (iad.ocir.io) and never publish :latest there, so every PR build's registry cache lookup 404s and rebuilds cold. Add a CACHE_REGISTRY knob (default ghcr.io/cozystack/cozystack, where release builds do publish :latest) and point every --cache-from at it. Push targets ($(REGISTRY)) and the unique per-PR tags are unchanged, so the #2711 anti-conflict behaviour is preserved while PR builds regain a warm cache from the last release. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request improves CI build performance by decoupling the registry used for pushing PR images from the registry used for pulling build caches. Previously, PR builds were attempting to pull caches from a per-CI registry that did not contain the necessary Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on Gemini (@gemini-code-assist) comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (32)
📝 WalkthroughWalkthroughThis PR introduces a ChangesBuild Cache Registry Configuration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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.
Code Review
This pull request introduces a CACHE_REGISTRY variable in hack/common-envs.mk and updates multiple package Makefiles to use it in the --cache-from argument of docker buildx build. This decouples the build cache source registry from the target push registry, allowing pull request builds to leverage warm caches from the main registry and avoid 404 errors. There are no review comments to evaluate, and I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
LGTM — surgical, correct fix; premise verified against source, change is complete and consistent, and #2711's anti-conflict tagging is preserved.
Business context: PR builds set REGISTRY to a per-CI registry that never publishes :latest (PUBLISH_FLOATING=0), so the old --cache-from $(REGISTRY)/<img>:latest always 404'd and rebuilt cold — pushing loaded runners into the 30-min timeout. This points --cache-from at ghcr, where releases do publish :latest.
Verified:
- Premise holds.
pull-requests.yamlsetsREGISTRYto a per-CI registry withPUBLISH_VERSIONED=0/PUBLISH_FLOATING=0; perimage-tagsincommon-envs.mk,:latestis only pushed whenPUBLISH_FLOATING=1, so it never lands on the per-CI registry.tags.yamlsets both to1with the default ghcrREGISTRY, so releases publish:latest/:<version>to ghcr — a valid warm cache source. - Completeness. All 37
--cache-fromrefs across 31 Makefiles now use$(CACHE_REGISTRY); zero$(REGISTRY)cache-from refs remain.cache-to(inline) and push targets ($(REGISTRY)) are untouched, so #2711's uniquepr-<N>-<sha>tagging is preserved. - Correctness. Inline cache is digest-matched, so reading cache from a registry different from the push target is safe — it can only change build speed, never output.
- The non-
:latestcase (ubuntu-container-disk:$(ver)) is consistent: releases publish that versioned tag to ghcr underPUBLISH_VERSIONED=1.
Non-blocking follow-ups:
- Downstream/fork builders who set a custom
REGISTRYand relied oncache-fromreading their own registry now default to upstream ghcr; they must also setCACHE_REGISTRY. It's a?=override, so this is minor — worth a line in build docs if any exist. - The deferred
:buildcache-from-main tag (already noted as out of scope) would restore PR-to-PR cache freshness between releases.
Follows cozystack#2855. The talos-csr-signer image target was added on this branch before cozystack#2855 merged, so the rebase brought it in still pointing --cache-from at $(REGISTRY)/talos-csr-signer:latest, which on PR CI is the per-CI registry where :latest is never published. That cache lookup 404s on every PR build and forces a cold rebuild, exactly the failure mode cozystack#2855 fixed for the other Makefiles. Aligns the only remaining $(REGISTRY)-targeted --cache-from with the $(CACHE_REGISTRY) ghcr.io convention from cozystack#2855 so PR builds of this target warm-start off the last release's :latest. Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
What this PR does
#2711 moved PR builds to unique
pr-<N>-<sha>tags (PUBLISH_FLOATING=0) to end concurrent-push 409 conflicts, but left--cache-frompointing at$(REGISTRY)/<img>:latest. PR builds setREGISTRYto the per-CI registry, which never publishes:latest, so every PR build's registry cache lookup404s and rebuilds cold — slowing builds and, on a loaded runner, pushing them into the 30-minute job timeout.This adds a
CACHE_REGISTRYknob (defaultghcr.io/cozystack/cozystack, where release builds do publish:latest) and points every--cache-fromat it. Push targets ($(REGISTRY)) and the unique per-PR tags are unchanged, so #2711's anti-conflict behaviour is preserved while PR builds regain a warm cache from the last release.hack/common-envs.mk: newCACHE_REGISTRY ?= ghcr.io/cozystack/cozystackwith rationale.--cache-from type=registry,ref=$(REGISTRY)/…→$(CACHE_REGISTRY)/….Verified with
make -n image REGISTRY=iad.ocir.io/…: push tag stays on OCIR (…/cozystack-controller:pr-<N>-<sha>), cache-from now readsghcr.io/cozystack/cozystack/cozystack-controller:latest. Makefile-only change — no generated artifacts affected.Release note
Summary by CodeRabbit