From 7051164731ccd69e94ad8d881f6edfd1dd268603 Mon Sep 17 00:00:00 2001 From: cplieger <917744+cplieger@users.noreply.github.com> Date: Wed, 5 Aug 2026 01:37:33 +0200 Subject: [PATCH] fix(renovate): hold docker/buildx bumps for 3 days MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 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. --- default.json | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/default.json b/default.json index 3703b14..3e62235 100644 --- a/default.json +++ b/default.json @@ -292,6 +292,16 @@ ], "minimumReleaseAge": "1 day" }, + { + "description": "docker/buildx: wait 3 days before bumping the BUILDX_VERSION pin in cplieger/ci's docker-release.yaml. 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 buildx release. Bumping the pin inside that window fails EVERY docker release in the fleet with 'Cannot find Buildx release in releases JSON', and nothing catches it pre-merge: ci.yaml's build-ability job passes no version input, so every PR stays green while every post-merge release dies. Cost the fleet a release outage on 2026-08-04 (buildx v0.36.1 published 15:50Z, Renovate landed it 16:02Z, the JSON still lacked it 7+ hours later; web-terminal-kiro, web-terminal-server and vibekit all failed). 3 days rather than the golang rule's 1 day because that JSON's bot is irregular (updates observed 2026-07-23, -28, -30) and a day would not have covered this incident; it also matches the npm bake window config:best-practices already imposes. Only cplieger/ci pins buildx, so this is a no-op everywhere else.", + "matchDatasources": [ + "github-releases" + ], + "matchDepNames": [ + "docker/buildx" + ], + "minimumReleaseAge": "3 days" + }, { "description": "Plex (plexinc/pms-docker): tags are ...-. Parse them so build-number bumps are detected while the per-release commit hash is ignored. Default docker versioning otherwise treats the - suffix as a fixed variant/compatibility tag and never finds a newer image sharing that exact suffix, so no update is ever offered (this once froze a pinned image from updating after its reference gained a docker.io/ registry prefix). Only one private consumer references this image, so this is a no-op for every other repo.", "matchPackageNames": [