fix(ci): create buildx builder in the build step's DOCKER_CONFIG - #2962
Conversation
The "Set up Buildx" step in build-main.yaml ran without DOCKER_CONFIG, so docker/setup-buildx-action created the docker-container builder under the default ~/.docker. The build step runs with DOCKER_CONFIG=$RUNNER_TEMP/.docker (seeded before the builder existed and holding the OCIR auth), so it could not find the builder and failed immediately with `no builder "builder-<uuid>" found`. The post-job `docker buildx rm` still succeeded because the action's cleanup runs under the default config where the builder actually lived. Set DOCKER_CONFIG on the Set up Buildx step so the builder instance is created in the same config the build step reads. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
|
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 (1)
📝 WalkthroughWalkthroughIn the ChangesCI Buildx Config Fix
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 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 |
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
LGTM — the fix correctly aligns the buildx builder's config store with the build step's DOCKER_CONFIG; mechanism verified end-to-end against the workflow.
Business context: the main cache-warmer (build-main.yaml, #2948) failed on its first run because the buildx builder was created in the default ~/.docker while the build step reads DOCKER_CONFIG=$RUNNER_TEMP/.docker, so --builder couldn't find it ("no builder found").
Verified end-to-end: "Set up Docker config" seeds $RUNNER_TEMP/.docker, "Login to OCIR" writes the auth there, and the build step reads BUILDER from steps.buildx.outputs.name under that same config — so creating the builder instance under the same DOCKER_CONFIG is the right and minimal fix. No blockers.
Non-blocking follow-up
DOCKER_CONFIG: ${{ runner.temp }}/.dockeris now repeated on three steps (login, buildx setup, build). Hoisting it to the job-levelenv:would make thewarm-cachejob self-consistent by construction and prevent exactly this "forgot it on one step" foot-gun from recurring. Optional — the per-step form here is correct as-is.
What this PR does
The
Build cache (main)workflow (build-main.yaml, added in #2948) failed onits first run: https://github.com/cozystack/cozystack/actions/runs/27929277423
The
Set up Buildxstep ran withoutDOCKER_CONFIG, sodocker/setup-buildx-actioncreated the docker-container builder under therunner's default
~/.docker. The build step runs withDOCKER_CONFIG=$RUNNER_TEMP/.docker(seeded earlier, holding the OCIR auth), sobuildx couldn't find the builder and failed immediately:
The post-job
docker buildx rmstill succeeded — because the action's cleanupruns under the default config where the builder actually lived — which confirms
the builder existed but in the wrong config store.
This sets
DOCKER_CONFIGon theSet up Buildxstep so the builder instance iscreated in the same config the build step reads.
Impact: only the main cache-warmer was broken. PR builds
--cache-fromthisref, so a missing cache is a cold build, not a failure — but the warm-cache
speedup from #2948 wasn't being delivered until this fix.
Release note
Summary by CodeRabbit