ci: cache buildkit image so buildx setup survives Docker Hub outages#21741
Merged
Conversation
docker/setup-buildx-action boots BuildKit by pulling moby/buildkit from Docker Hub on every run — the last uncached Docker Hub dependency in the kurtosis jobs. In merge-queue run 27280175556 that pull timed out (`Get "https://registry-1.docker.io/v2/": context deadline exceeded`), failing the CI Gate. #21735 added a retry, but a retry doesn't survive an outage longer than its window. Pin the BuildKit image (buildx-stable-1 currently resolves to v0.30.0) via driver-opts, cache it with the established docker save/load + actions/cache pattern, and pre-load it before buildx setup. buildx falls back to a locally present image when its pull fails, so with a warm cache the builder boots even while Docker Hub is unreachable. The cache-fill pull in the test jobs is best-effort (continue-on-error): buildx pulls the image itself either way, so a failed seed must not fail an otherwise-good run. Warm jobs pull strictly — producing the cache is their purpose. Both warming workflows already path-filter on the edited files, so the cache is created on main right after merge and refreshed daily against LRU eviction. One key (docker-buildkit-<image>) is shared by the assertoor and gloas workflows.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR reduces CI flakiness caused by Docker Hub outages during docker/setup-buildx-action by pinning the BuildKit image and caching it so Buildx can bootstrap from a locally loaded copy when registry pulls fail.
Changes:
- Pin BuildKit to
moby/buildkit:v0.30.0and pass it todocker/setup-buildx-actionviadriver-opts: image=...(assertoor + gloas). - Add
actions/cache-backeddocker save/loadcaching for the BuildKit image under a shareddocker-buildkit-<image>key, with best-effort cache seeding in test jobs. - Extend the existing default-branch cache-warming workflows/documentation to include the new BuildKit cache.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| .github/workflows/test-kurtosis-gloas.yml | Adds pinned BuildKit image, restores/loads it before Buildx setup, and warms/saves a shared BuildKit cache key. |
| .github/workflows/test-kurtosis-assertoor.yml | Adds pinned BuildKit image, restores/loads it before Buildx setup (including retry path), and warms/saves a shared BuildKit cache key. |
| .github/workflows/cache-warming-kurtosis-gloas-images.yml | Updates workflow documentation to reflect warming both third-party and BuildKit caches. |
| .github/workflows/cache-warming-kurtosis-cl-images.yml | Updates workflow documentation to reflect warming both third-party and BuildKit caches. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
lystopad
approved these changes
Jun 11, 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
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.
Why
docker/setup-buildx-actionboots BuildKit by pullingmoby/buildkitfrom Docker Hub on every run — the last uncached Docker Hub dependency in the kurtosis jobs. In merge-queue run 27280175556 that pull timed out (Get "https://registry-1.docker.io/v2/": context deadline exceeded), failing the CI Gate for #21723 — ironically the PR closing the equivalent gap for the kurtosis engine-bootstrap images. The same Docker Hub connectivity window took out three other CI Gate runs that morning at thekurtosis engine startstep.#21735 added a retry around buildx setup, but a retry doesn't survive an outage longer than its window. This removes the hard dependency the same way as the rest of the image-caching series (#21695, #21703, #21723).
What
BUILDKIT_IMAGE: moby/buildkit:v0.30.0(what the movingbuildx-stable-1tag currently resolves to) and pass it tosetup-buildx-actionviadriver-opts: image=..., in bothtest-kurtosis-assertoor.yml(build-erigon-image) andtest-kurtosis-gloas.yml(gloas_test). Bump alongside the other pinned images.docker-buildkit-<image>) with the established docker save/load + actions/cache pattern, anddocker loadit before buildx setup. buildx's docker-container driver falls back to a locally present image when its pull fails ("pulling failed, using local image"), so with a warm cache the builder boots even while Docker Hub is fully unreachable. Pinning via driver-opts is what makes the fallback engage — the local image name must match what buildx wants to boot.continue-on-error, save gated on pull success): buildx pulls the image itself either way, so a failed seed must not fail an otherwise-good run, and a failed pull never poisons the cache key with an empty archive.warm-third-party-imagesin both files) pull strictly and save the same key — producing the cache is their purpose. Both cache-warming workflows already path-filter on the edited files, so the cache is created on main right after this merges and refreshed daily against LRU eviction.In gloas, buildx setup previously ran before any caching; the buildkit cache steps are inserted ahead of it.
Not covered (non-gating, can follow up if wanted):
ci-cd-main-branch-docker-images.ymlandrelease.ymlalso usesetup-buildx-actionbut don't block PRs or the merge queue.actionlint is clean (the two SC2086 infos it reports pre-exist on main in the kurtosis CLI install step).