Repository navigation
Avoid duplicate BuildKit discovery during Gen2 setup - #5
Merged
Merged
Conversation
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.
Warm Gen2 setup spent 7.2 of 13.7 seconds running a separate Buildx inspection. The subsequent build discovers the same embedded BuildKit worker again. Remove that duplicate discovery while retaining backend verification, cold-wake waiting, local Buildx installation checks, bounded Docker readiness probes, and isolated cleanup.
All 30 action tests pass, including unavailable Docker, failed readiness cleanup, and rejecting a non-Docker driver before publishing outputs.
Live A/B qualification used the same test client and AWS/EBS builder, with three alternating samples per variant and a fresh CLI install and forced Docker RUN in every sample. Median setup fell from 21.26s to 10.77s; setup excluding variable CLI installation fell from 10.42s to 3.19s. Setup plus the first build fell from 37.68s to 28.52s. First-build median was 17.64s before and 16.28s after, so the saved setup work did not move into the build. These local-client timings are separate from the original customer CI trace.
Published v2.0.1 and updated
2/v2. The existing customer gateway job rerun resolved action commit35b4d3c5f44efd7f625f94774f29caf208046614: warm setup fell from 13.7s to 7.5s (45% faster), and the image build passed without a retry. CLI installation remained 2.1s in both runs. Builder readiness preceded the measured action step. No customer source or workflow edits were made.