Stale-test fix: discourse upgrade-tier base selection vs the 0.8→1.0 structural break
Stale behavior: the dynamic upgrade-base resolver (phase prevb/samever) steps back from the
unbumped 1.0.0+3.5.3 version label to 0.8.1+3.5.0 — crossing the bitnami→official db-family
break (pgvector/pg17 → discourse/postgres:pg18; the bitnami cluster has no discourse role and
pg_upgrade preserves-not-creates roles). That in-place path has never been supported upstream and
can never converge, so the upgrade tier red'd twice on it (drone #1165 on 2026-07-31, #1171 in the
2026-08-03 weekly run) while the recipe's real official→official path verified green both times.
The fix — UPGRADE_BASE_FLOOR (phase basefloor): a recipe_meta declaration naming the first
post-break published version. Resolution stays fully dynamic (this is not the §2.G-removed
static pin): the floor only excludes structurally-impossible candidates in all three resolver
paths (canonical / step-back / no-canonical fallback); if no ≥-floor predecessor exists the tier
records a declared skip — never a silent pass. tests/discourse/recipe_meta.py declares UPGRADE_BASE_FLOOR = "1.0.0+3.5.3" with the full rationale in place.
Unit-verified: head 1.0.0+3.5.3 → declared skip (previously: wrong 0.8.1+3.5.0 pick);
post-release head 2.x+2026.7.1 → base 1.0.0+3.5.3, the real migration path. Once the operator
runs abra recipe release discourse, the tier automatically tests official→official again.
No assertion weakened — below-floor in-place upgrades were never supported coverage; the skip
is declared and recorded in the RUN SUMMARY.
Paired recipe PR: recipe-maintainers/discourse#6 (2026.7.1 bump,
verified green by direct deploy in the weekly run). Full-suite verification with this branch runs
next (serialized behind the in-flight mailu re-verification build); merged on green per policy.
## Stale-test fix: discourse upgrade-tier base selection vs the 0.8→1.0 structural break
**Stale behavior:** the dynamic upgrade-base resolver (phase prevb/samever) steps back from the
unbumped `1.0.0+3.5.3` version label to `0.8.1+3.5.0` — crossing the **bitnami→official db-family
break** (pgvector/pg17 → discourse/postgres:pg18; the bitnami cluster has no `discourse` role and
pg_upgrade preserves-not-creates roles). That in-place path has never been supported upstream and
can never converge, so the upgrade tier red'd twice on it (drone #1165 on 2026-07-31, #1171 in the
2026-08-03 weekly run) while the recipe's real official→official path verified green both times.
**The fix — `UPGRADE_BASE_FLOOR` (phase basefloor):** a recipe_meta declaration naming the first
post-break published version. Resolution stays fully **dynamic** (this is not the §2.G-removed
static pin): the floor only *excludes* structurally-impossible candidates in all three resolver
paths (canonical / step-back / no-canonical fallback); if no ≥-floor predecessor exists the tier
records a **declared skip** — never a silent pass. `tests/discourse/recipe_meta.py` declares
`UPGRADE_BASE_FLOOR = "1.0.0+3.5.3"` with the full rationale in place.
**Unit-verified:** head `1.0.0+3.5.3` → declared skip (previously: wrong `0.8.1+3.5.0` pick);
post-release head `2.x+2026.7.1` → base `1.0.0+3.5.3`, the real migration path. Once the operator
runs `abra recipe release discourse`, the tier automatically tests official→official again.
**No assertion weakened** — below-floor in-place upgrades were never supported coverage; the skip
is declared and recorded in the RUN SUMMARY.
Paired recipe PR: https://git.autonomic.zone/recipe-maintainers/discourse/pulls/6 (2026.7.1 bump,
verified green by direct deploy in the weekly run). Full-suite verification with this branch runs
next (serialized behind the in-flight mailu re-verification build); merged on green per policy.
The 0.8.x->1.0.0 discourse recipe family switched app bitnami->official AND db
pgvector/pg17->discourse/postgres:pg18. That db-family change is a structural
break (bitnami cluster lacks the discourse role; pg_upgrade preserves-not-creates
roles) with NO supported in-place path. The dynamic base resolver's step-back
kept selecting 0.8.1+3.5.0 (newest tag below the unbumped 1.0.0+3.5.3 label) and
the upgrade tier red'd twice on this unsupported path (drone #1165, #1171 —
classified stale-test both times; recipe verified green on the real
official->official path).
Adds UPGRADE_BASE_FLOOR (phase basefloor) to resolve_upgrade_base: a recipe_meta
declaration naming the first post-break published version. Resolution stays
fully dynamic (this is NOT the removed sec2.G static pin): the floor only
EXCLUDES below-floor candidates (canonical, step-back, no-canonical fallback);
when no >=floor predecessor exists the tier records a DECLARED skip, never a
silent pass. main-tip fallback unaffected (post-break by construction).
tests/discourse/recipe_meta.py declares UPGRADE_BASE_FLOOR = 1.0.0+3.5.3 with
the full rationale. Unit-verified: head=1.0.0+3.5.3 -> declared skip (was:
0.8.1+3.5.0 wrong pick); post-release head=2026.x -> base 1.0.0+3.5.3 (the real
migration path). No assertion weakened - below-floor in-place upgrades were
never supported coverage.
autonomic-bot
requested review from trav 2026-08-04 17:15:56 +00:00
autonomic-bot
requested review from notplants 2026-08-04 17:15:57 +00:00
The strict recipe_meta key registry rejected the new declaration (caught by
verify run 1). str-typed, default None; full semantics documented on the key.
test_head_runs_official_image_not_bitnamilegacy hardcoded the migration-era pin
discourse/discourse:3.5.3 and went stale on the first legitimate app bump
(2026.7.1, weekly 2026-08-03 — caught by verify run 2: the upgrade converged,
head image was discourse/discourse:2026.7.1, only the frozen pin failed). The
guarded property is the image FAMILY (official vs bitnamilegacy), not a frozen
version — now asserts the discourse/discourse: prefix. Not weakened: the
bitnami-leak check + official-prefix check together still assert exactly the
migration faithfulness; the concrete head pin is exercised by the deploy.
Verified GREEN — cold full-suite ×1, level 5 of 5 paired with discourse recipe PR #6 head (bfa21bc4), log verify-discourse-20260804T174918Z.1.log:
install/upgrade/backup/restore/custom all pass. The upgrade tier resolved base = main-tip (official family — the floor correctly excluded the structurally-invalid 0.8.x bases), converged to the head's discourse/discourse:2026.7.1, and the now version-agnostic faithfulness assertions passed.
Three iterations, all documented: (1) meta key-registry entry missing → registered; (2) the original stale hardcoded :3.5.3 pin surfaced → made version-agnostic (family assertion, not weakened); (3) full green. Two intermediate 401s were transient git.autonomic.zone blips, not fix iterations.
Merging directly per policy (the /cc-ci-tests-update invocation is the authorization).
**Verified GREEN — cold full-suite ×1, level 5 of 5** paired with discourse recipe PR #6 head (`bfa21bc4`), log `verify-discourse-20260804T174918Z.1.log`:
install/upgrade/backup/restore/custom **all pass**. The upgrade tier resolved base = main-tip (official family — the floor correctly excluded the structurally-invalid 0.8.x bases), converged to the head's `discourse/discourse:2026.7.1`, and the now version-agnostic faithfulness assertions passed.
Three iterations, all documented: (1) meta key-registry entry missing → registered; (2) the original stale hardcoded `:3.5.3` pin surfaced → made version-agnostic (family assertion, not weakened); (3) full green. Two intermediate 401s were transient git.autonomic.zone blips, not fix iterations.
Merging directly per policy (the /cc-ci-tests-update invocation is the authorization).
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.
Stale-test fix: discourse upgrade-tier base selection vs the 0.8→1.0 structural break
Stale behavior: the dynamic upgrade-base resolver (phase prevb/samever) steps back from the
unbumped
1.0.0+3.5.3version label to0.8.1+3.5.0— crossing the bitnami→official db-familybreak (pgvector/pg17 → discourse/postgres:pg18; the bitnami cluster has no
discourserole andpg_upgrade preserves-not-creates roles). That in-place path has never been supported upstream and
can never converge, so the upgrade tier red'd twice on it (drone #1165 on 2026-07-31, #1171 in the
2026-08-03 weekly run) while the recipe's real official→official path verified green both times.
The fix —
UPGRADE_BASE_FLOOR(phase basefloor): a recipe_meta declaration naming the firstpost-break published version. Resolution stays fully dynamic (this is not the §2.G-removed
static pin): the floor only excludes structurally-impossible candidates in all three resolver
paths (canonical / step-back / no-canonical fallback); if no ≥-floor predecessor exists the tier
records a declared skip — never a silent pass.
tests/discourse/recipe_meta.pydeclaresUPGRADE_BASE_FLOOR = "1.0.0+3.5.3"with the full rationale in place.Unit-verified: head
1.0.0+3.5.3→ declared skip (previously: wrong0.8.1+3.5.0pick);post-release head
2.x+2026.7.1→ base1.0.0+3.5.3, the real migration path. Once the operatorruns
abra recipe release discourse, the tier automatically tests official→official again.No assertion weakened — below-floor in-place upgrades were never supported coverage; the skip
is declared and recorded in the RUN SUMMARY.
Paired recipe PR: recipe-maintainers/discourse#6 (2026.7.1 bump,
verified green by direct deploy in the weekly run). Full-suite verification with this branch runs
next (serialized behind the in-flight mailu re-verification build); merged on green per policy.
Verified GREEN — cold full-suite ×1, level 5 of 5 paired with discourse recipe PR #6 head (
bfa21bc4), logverify-discourse-20260804T174918Z.1.log:install/upgrade/backup/restore/custom all pass. The upgrade tier resolved base = main-tip (official family — the floor correctly excluded the structurally-invalid 0.8.x bases), converged to the head's
discourse/discourse:2026.7.1, and the now version-agnostic faithfulness assertions passed.Three iterations, all documented: (1) meta key-registry entry missing → registered; (2) the original stale hardcoded
:3.5.3pin surfaced → made version-agnostic (family assertion, not weakened); (3) full green. Two intermediate 401s were transient git.autonomic.zone blips, not fix iterations.Merging directly per policy (the /cc-ci-tests-update invocation is the authorization).