upgrade base: prefer the newest published release over a stale canonical #16
Open
autonomic-bot
wants to merge 1 commits from
test/upgrade-base-prefer-newest-release-20260810 into main
pull from: test/upgrade-base-prefer-newest-release-20260810
merge into: :main
:main
:policy/pr-then-merge
:fix/plausible-format
:fix/plausible-v3-custom-tests
:test/upgrade-base-prefer-newest-release-20260810
:test/discourse-upgrade-base-floor-20260804
:test/wordpress-enroll-20260803
:test/lasuite-meet-stale-test-20260803
:test/lasuite-docs-stale-test-20260803
:chore/server-flake-update-20260803
:redfix-m2-harness
:feat/libredesk-tests
:phase-lvl5
:fix/converged-oneshot
:restructure/recipe-custom
:restructure/concurrency
:fix/converge-paused-update
:test/plausible-psql-quiet
:fix/converge-rolling-update
:fix/lint-and-concurrent-runs
:test/plausible-upgrade-base-3.0.1
:chore/runner-capacity-2
:feat/reports-pr-status-proxy
:feat/expected-na-and-tiny-functional
:regression-canaries
:v6-custom-html-mime
:v6-custom-html-docroot
:v6-matrix-synapse-real-upgrade-state
:terraform-hetzner
:scratch/m3-demo
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Upgrade base: prefer the newest published release over a stale canonical
The canonical is last-green, not current. Its promotion (WC5) deploys a
warm-<recipe>app andhealth-checks it — when that fails the canonical stays pinned at an old release indefinitely, and
nothing in the upgrade tier notices.
This is not hypothetical. The 2026-08-09 sweep logged
GREEN-BUT-PROMOTE-FAILEDfor fiverecipes — bluesky-pds, drone, gitea, lasuite-drive, lasuite-meet — so their canonicals are frozen
(gitea's at
3.5.3+1.24.2-rootless, dated 2026-06-17, becausewarm-giteacrash-loops on aread-only
app.ini; open recipe fix: gitea PR #4).What it cost us
The gitea upgrade tier based on
3.5.3and went green, while the upgrade real installs perform wasbroken:
APP_INI_VERSION3.5.3 → head(what CI tested)3.6.1 → 3.6.2(what users run)only updates to Labels are allowedThat shipped in
3.6.2+1.27.1-rootlessand blocked every existing install from taking the 1.27.1security release (CVE-2026-60004, CVE-2026-59774).
The change
When the newest published release older than head is newer than the canonical, use the release
and log why — naming the stale canonical, so the failing promote gets noticed instead of silently
degrading coverage. Resolution stays dynamic;
UPGRADE_BASE_FLOORstill filters structurallyinvalid candidates; the canonical remains the base whenever it is current.
Unit-verified on the real gitea tag set: base moves
3.5.3+1.24.2-rootless→3.6.1+1.26.2-rootless— precisely the transition that reproduces the break.Follow-up (not in this PR)
The five failing WC5 promotes are a separate bug worth fixing at the source; this change stops them
from silently weakening upgrade coverage in the meantime.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.