fix(renovate): hold docker/buildx bumps for 3 days - #136
Merged
Conversation
setup-buildx-action does not download from the buildx release. It resolves the download URL from docker/actions-toolkit's .github/buildx-releases.json, a static file a bot regenerates AFTER each buildx release, so a BUILDX_VERSION pin bumped inside that window names a version the action cannot find and every docker release in the fleet fails with "Cannot find Buildx release <v> in releases JSON". Nothing caught it pre-merge, which is what made it expensive: ci.yaml's build-ability job passes no version input to the action, so every PR's `ci / docker` check stayed green while every post-merge release died. On 2026-08-04 buildx v0.36.1 published at 15:50Z, Renovate landed the bump at 16:02Z, and the JSON still lacked the entry 7 hours later; web-terminal-kiro, web-terminal-server and vibekit all failed to publish. Scoped to the one dep, in the shape the golang docker rule above it already uses for the same class of problem (a pin resolvable before the artifact it names is fully published). 3 days rather than that rule's 1 because the toolkit bot is irregular — observed 2026-07-23, -28 and -30 — so a day would not have covered this incident, and 3 matches the npm bake window config:best-practices already imposes. Only cplieger/ci pins buildx, so this is a no-op in every other repo.
cplieger
added a commit
to cplieger/ci
that referenced
this pull request
Aug 4, 2026
Every docker release in the fleet has been failing since 2026-08-04 with "Cannot find Buildx release v0.36.1 in releases JSON". setup-buildx-action does not download from the buildx release itself; it resolves the URL from docker/actions-toolkit's .github/buildx-releases.json, a static file a bot regenerates AFTER each release. buildx v0.36.1 published at 15:50Z, Renovate landed the pin at 16:02Z (#424), and the JSON still lacked the entry 7 hours later, so the version this workflow asks for does not exist as far as the action is concerned. Nothing caught it before merge: ci.yaml's build-ability job passes NO version input to the action, so every PR's `ci / docker` check stayed green while every post-merge release died. Confirmed on web-terminal-kiro, web-terminal-server and vibekit; a rerun failed identically. Rolling back to v0.36.0, which the JSON does carry, restores releases now. The durable guard is a 3-day minimumReleaseAge for docker/buildx in the shared preset (cplieger/.github#136), landed first so Renovate cannot re-propose v0.36.1 into the same hole; v0.36.1 becomes eligible again on 2026-08-07, by which point the JSON will have it.
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.
Summary
Adds a 3-day
minimumReleaseAgefordocker/buildx, scoped to that one dep.setup-buildx-actiondoes not download from the buildx release. It resolves the download URL fromdocker/actions-toolkit's.github/buildx-releases.json, a static file a bot regenerates after each buildx release. ABUILDX_VERSIONpin bumped inside that window names a version the action cannot find, and every docker release in the fleet fails:Why it went unnoticed until it broke three repos
ci.yaml's build-ability job passes noversioninput to the action, so it always resolves fine. Onlydocker-release.yamlpasses the pin. The result is that every PR'sci / dockercheck goes green while every post-merge release dies — the failure is invisible until something merges.On 2026-08-04, buildx v0.36.1 published at 15:50Z and Renovate landed the bump 12 minutes later at 16:02Z (cplieger/ci#424). The JSON still did not carry the entry 7 hours after that (verified by direct fetch: 137 entries, no
v0.36.1). web-terminal-kiro, web-terminal-server and vibekit all failed to publish; a rerun failed identically.Shape and value
Modelled on the
golangdocker rule directly above it, which exists for the same class of problem: a pin Renovate can resolve before the artifact it names is fully published.3 days rather than that rule's 1 day, because the toolkit bot is irregular (updates observed 2026-07-23, -28, -30) and a single day would not have covered this incident. It also matches the npm bake window
config:best-practicesalready imposes fleet-wide. v0.36.1 becomes eligible again on 2026-08-07, by which point the JSON will carry it.Only
cplieger/cipins buildx, so this is a no-op in every other repo.Companion change
cplieger/ci rolls
BUILDX_VERSIONback to v0.36.0 to unblock releases now. Landing this first means the guard is in place before that revert, so Renovate cannot immediately re-propose v0.36.1 into the same hole.