ci: speed up multi-arch build with Go + layer caching - #802
Merged
Conversation
jacksontj
changed the title
The `build` workflow spent ~10m almost entirely in buildx. The Dockerfile cross-compiles (`$BUILDPLATFORM`, `CGO_ENABLED=0`), so the four arches aren't QEMU-emulated — they're four native cross-compiles. But every push did `COPY . …` → full `go build` of promxy + all of vendor, once per platform, from a cold Go build cache, with no layer cache between runs. - Dockerfile: add per-arch `--mount=type=cache,target=/root/.cache/go-build` mounts so the Go build cache is reused across the four platform builds. - build.yml: drive the build via docker/build-push-action@v6 with cache-from/to type=gha so that cache and the image layers also persist across runs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Why
The
buildworkflow (multi-arch docker, runs on master push + tags) spends ~10m almost entirely in one step:buildRun Buildx= 10m12sThe Dockerfile cross-compiles (
$BUILDPLATFORM,CGO_ENABLED=0), so the four arches aren't emulated under QEMU — they're four native cross-compiles. But every push didCOPY . …→ fullgo buildof promxy + all of vendor, ×4 platforms, from a cold build cache, with no layer cache between runs.What
--mount=type=cache,target=/root/.cache/go-buildmounts so the Go build cache is reused across the four platform builds.docker/build-push-action@v6andcache-from/to: type=ghaso that cache (and image layers) also persists across runs.Expected: ~10m → ~2–3m on warm cache. The first run still populates the cache.
Notes
checkout@v4/docker/setup-*@v3/azure/docker-login@v2are already on their latest majors — nothing to bump yet.Gotest workflow's lint and test into parallel jobs, but dropped it: the jobs run on separate runners (no shared build cache mid-run) and staticcheck (non-race) vsgo test -racecompile different artifacts, so it traded a whole extra runner for a marginal wall-clock gain.go.ymlis unchanged.master(already Go 1.25), independent of the in-flight OCI branch.🤖 Generated with Claude Code