recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
cfb341e244aff98ec775a980ee5fcbea01e57c4b
cc-ci/machine-docs/JOURNAL-samever.md
autonomic-bot 96c4ad9ef3
All checks were successful
continuous-integration/drone/push Build is passing
Details
claim(M2): samever proven in real CI — step-back base<head, version-bump unaffected, discourse #4 + hedgedoc spot-check 
5 real cc-ci runs (samever-deploy @ cc-ci main): Run B nightly steady-state step-back
custom-html 1.11.0+1.29.0→1.13.0+1.31.1 (base<head real delta, 5 tiers green); Run C
version-bump UNAFFECTED (last-green path); Run D PR-form step-back (ref set); discourse #4
kind=ref main-tip unaffected (migration 0.8.1→1.0.0 green); hedgedoc spot-check step-back
3.0.9→3.0.10 green. WHAT/HOW/EXPECTED/WHERE in STATUS-samever.md; logs /root/samever-*.log,
artifacts /var/lib/cc-ci-runs/samever-*/ on cc-ci.
2026-06-17 04:58:48 +00:00

7.3 KiB
Raw Blame History

JOURNAL — phase samever (Builder reasoning; Adversary does not read before verdict)

2026-06-17 — M1 design + implementation

Root cause (confirmed against runner/run_recipe_ci.py): the warm-canonical path of resolve_upgrade_base returned BasePlan("version", rec["version"], …) unconditionally — it was never given the head's version, only head_ref (a commit sha), so it could not detect the canonical==head collision. The ref (main-tip) path was already guarded (main_tip == head_ref → skip); the version path was not. In the nightly steady state a green cold-on-latest run promotes canonical → latest, so the next night finds canonical == latest == version-under-test and the upgrade tier deploys base==head: a vacuous same-version "upgrade."

Why pass head_version as a param rather than read compose inside the resolver: keeps the resolver pure/unit-testable (the existing 8 tests inject canonical.read_registry / lifecycle.recipe_branch_commit via monkeypatch and never touch the filesystem). The call site (main()) reads it once via abra.head_compose_version(recipe) from the head checkout that already exists on disk. Tests pass head_version= directly.

Why version_key-based equality instead of raw string ==: the canonical record version and the compose label should be byte-identical when equal, but routing both through the existing coop-cloud ordering key (warm_reconcile.version_key) means a re-published or incidentally-reformatted equal version still compares equal, and the step-back's "strictly older" uses the same single ordering source — no hand-rolled semver (plan §2 constraint). version_key is the inner key of the existing sort_versions, lifted out so sort_versions/newest_older_version share it (no behavior change to sort_versions — verified by the unchanged existing warm_reconcile tests).

Why the step-back inherits F1d-2 automatically: it returns kind="version" exactly like the normal canonical base, so it flows through the same deploy path (abra.recipe_checkout pins the tag on disk, non-chaos deploy) — the chosen older base genuinely deploys that pinned version, never LATEST. No new deploy code; the protection is structural.

Skip only when genuinely no older predecessor: newest_older_version returns None only when the head version is the oldest (or only) published tag — then, and only then, a declared skip ("base == head … and no older published predecessor"), never a same-version no-op.

head_version is None (compose unreadable / no label): cannot compare → same=False → preserves prevb behavior exactly (canonical is primary). No regression for any caller that omits head_version; the existing test_last_green_warm_canonical_is_primary still passes unchanged.

Pre-existing unrelated failures (confirmed failing on clean 279d84d with my changes stashed, so NOT introduced here): tests/unit/test_meta.py::test_generated_doc_table_in_sync and tests/unit/test_warm_reconcile.py::test_traefik_spec_is_stateless_with_setup (KeyError 'health_domain'). Out of scope for samever.

2026-06-17T04:25Z — M1 claimed; M2 prep (no gate runs until M1 PASS)

M1 claimed (c5a0d20). Parked at gate; doing read-only M2 prep:

  • Trigger mechanism (from prevb M2): !testme on a recipe PR → bridge (polls 30s) → Drone build of cc-ci@main (now = samever code) → artifacts at /var/lib/cc-ci-runs/<N>/ (junit/results.json, Adversary-readable). Local full-pipeline runs on cc-ci de-risk before posting.
  • Enrolled (WARM_CANONICAL=True) recipes: only custom-html currently. No canonical registries on cc-ci right now (/var/lib/cc-ci-canonical/ empty).
  • M2 plan shape: (1) nightly steady state — seed custom-html canonical registry version = its LATEST published tag, run cold-on-latest → assert upgrade tier kind=version, base_version < latest (step-back, genuine delta, not no-op/skip). (2) PR form — non-version-bump PR, head==canonical, same step-back. (3) discourse #4 version-bump → UNAFFECTED (canonical→head). (4) spot-check ≥1 other enrolled recipe (only custom-html enrolled today — resolve during M2: enroll/seed a 2nd, or use the registry mechanism on another recipe). Need ≥2 published tags on the step-back recipe for an older target to exist — verify custom-html tag count before run.

2026-06-17T04:40Z — M2 real-CI evidence captured (custom-html + discourse)

Two-run authentic nightly simulation on cc-ci (/root/samever-deploy @ cc-ci main, samever code):

  • Run A (cold-on-latest, no canonical): upgrade base kind=skip (head==main tip); green 5 tiers; WC5 promote → canonical custom-html = 1.13.0+1.31.1 (the "first nightly").
  • Run B = THE HEADLINE (2nd consecutive nightly, canonical==latest==head): upgrade base: kind=version version=1.11.0+1.29.0 (step-back: last-green canonical (1.13.0+1.31.1) == head version 1.13.0+1.31.1; newest older published base). Upgrade tier deployed base 1.11.0+1.29.0 then chaos-upgraded to head: version=1.11.0+1.29.0→1.13.0+1.31.1 (label MOVED, base<head, REAL delta — not a no-op, not a skip). All 5 tiers green. Proves F1d-2: the older base actually deployed the pinned 1.11.0 then upgraded to 1.13.0.
  • Run C (version-bump UNAFFECTED, enrolled): re-seeded canonical→OLDER 1.11.0+1.29.0, cold-on-latest head 1.13.0 → kind=version version=1.11.0+1.29.0 (last-green (warm canonical, status=idle)) — reason "last-green", NOT "step-back": the unchanged prevb path. Upgrade 1.11.0→1.13.0 green. The step-back never engages when canonical≠head.
  • discourse #4 (non-enrolled version-bump, REF=ae5a8180): kind=ref ref=f87c612d71b4 (target-branch (main) tip) — byte-identical to prevb run 717; discourse never enters the canonical branch, so samever cannot perturb it. (Full install,upgrade migration running to green for completeness.)

Artifacts preserved on cc-ci: /root/samever-run{A,B,C}.log, /root/samever-disc4.log; run B/C results copied to /var/lib/cc-ci-runs/samever-run{B,C}/ (Adversary-readable).

2026-06-17T04:55Z — M2 complete (PR form + spot-check), claiming

  • Run D (PR form): ran custom-html with REF=2b82ebab PR=999 (a PR head whose compose version is still 1.13.0 == canonical). Resolver stepped back to 1.11.0+1.29.0 even with the ref present — confirming the step-back is ref-independent (the canonical branch precedes the main-tip/ref path). Upgrade 1.11.0→1.13.0 green.
  • Spot-check (hedgedoc): only custom-html is WARM_CANONICAL-enrolled, so to exercise the resolver on a SECOND recipe + different tag ordering I hand-seeded hedgedoc's canonical record to its latest (3.0.10+1.10.8) — the resolver reads canonical.read_registry regardless of enrollment, so this is the same production code path. cold-on-latest → step-back to 3.0.9+1.10.7, upgrade green. Removed the seeded record afterward (rm -rf /var/lib/ci-warm/hedgedoc) to leave clean state; hedgedoc is not enrolled and would be pruned anyway.
  • State hygiene: custom-html canonical left at the legitimately-promoted 1.13.0+1.31.1 (its real enrolled steady state). No leftover run stacks (clean teardown verified). Pre-existing warm-keycloak orphan untouched.

Design B (canonical history) is already recorded out-of-scope in cc-ci-plan/IDEAS.md (per plan §5) — verify before DONE.