Repository navigation
Release 0.6.2: serialize image builds of the same commit - #24
Merged
Merged
Conversation
A push to a PR branch starts a push run and a pull_request run for the same commit, and both build the image into the same gha cache. Two concurrent cache writes can stall buildx for many minutes. Group the image job by the commit being built so the second run waits for the first, then finds a fresh cache. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <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
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.
Every push to a PR branch starts two runs for the same commit, the push run and the pull_request run, and both build the image into the same GitHub Actions cache. Two builds writing that cache at once is a known way for buildx to stall. Another project using this CI setup had a PR run hang in the build step for 17+ minutes while its twin finished in 83 seconds. The re-run took 57 seconds, and GitHub reported no incident.
Change
The
imagejob gets a concurrency group keyed by the commit being built (pull_request.head.sha, falling back togithub.sha), withcancel-in-progress: false. The second run's image build waits for the first, then finds a fresh cache.It's on the job, not the whole workflow, so:
Tags, publishing, releases and the
stablemove don't change.One GitHub quirk: a concurrency group holds one running job and one pending job. A third run for the same commit, such as a manual
workflow_dispatchwhile both are queued, cancels the pending one. That's rare, and a re-run fixes it.Release
Bumps to 0.6.2 (patch: nothing for users to do) with
docs/releases/0.6.2.md.🤖 Generated with Claude Code