Files

autonomic-bot a7317a54fb

continuous-integration/drone/push Build is passing

Details

review(regall): batches 5-6 verified; A-regall-2 filed for plausible backup_restore=fail

Batch 5 results:
- uptime-kuma (748): L5 all pass ✓
- lasuite-drive (749): L5 all pass ✓
- plausible (750): L2, backup_restore=FAIL — regression from baseline L5
  - ci_marker not found after restore; no-op upgrade (3.0.1+v2.0.0→3.0.1+v2.0.0)
  - Builder re-running as Drone 754

Batch 6 results:
- custom-html-tiny (752): L5, upgrade=pass, backup_restore=skip (expected) ✓
- bluesky-pds (753): L5, upgrade=skip (expected/EXPECTED_NA), backup_restore=pass ✓

A-regall-2: plausible backup_restore=fail — prevb regression or flake TBD.
Run 750 shows no-op upgrade (prevb UPGRADE_BASE_VERSION path) vs baseline run 658 genuine upgrade (git ref).
Same failure seen in m2r/m2rr-plausible during prevb development.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-06-17 02:32:26 +00:00

4.6 KiB

Raw Blame History

BACKLOG — phase `regall`

Build backlog

Batch 1 (in flight)

B1a: Trigger !testme on drone PR#1 (upgrade=p baseline, open PR)
B1b: Trigger !testme on gitea PR#1 (upgrade=p baseline, open PR)
B1c: Trigger !testme on matrix-synapse PR#4 (upgrade=p baseline, open PR)

Batch 2 (queued)

B2a: Trigger !testme on mumble PR#1
B2b: Trigger !testme on lasuite-meet PR#7
B2c: Trigger !testme on n8n PR#6

Batch 3 (queued)

B3a: Trigger !testme on custom-html PR#5
B3b: Trigger !testme on mattermost-lts PR#2
B3c: Trigger !testme on mailu PR#4

Batch 4 (queued — recipes without open PRs need trivial PRs created)

B4a: ghost — create trivial PR + !testme
B4b: immich — create trivial PR + !testme
B4c: lasuite-docs — create trivial PR + !testme

Batch 5 (queued)

B5a: lasuite-drive — create trivial PR + !testme
B5b: plausible — create trivial PR + !testme (has UPGRADE_BASE_VERSION override)
B5c: uptime-kuma — create trivial PR + !testme

Batch 6 (queued)

B6a: custom-html-tiny — create trivial PR + !testme
B6b: bluesky-pds PR#3 (upgrade=skip, lower risk but still needs sweep)

Post-sweep

B7: Build results table + classify any regressions
B8: Fix any prevb-caused regressions (if any)
B9: Re-verify fixes (if any)
B10: Claim M1 gate (all run + classified)
B11: Claim M2 gate (regressions fixed + verified)

Adversary findings

A-regall-2 [adversary] OPEN @2026-06-17T03:25Z — plausible backup_restore=fail; classify prevb regression or flake

Filed: 2026-06-17T03:25Z Severity: MEDIUM — backup_restore failure drops plausible from baseline L5 to L2. Blocks M1 classification.

Run: 750 (Drone 750, PR#4). Result: level=2, backup_restore=fail. Baseline: run 658, level=5, backup_restore=pass.

Failure: test_restore_returns_state — ERROR: relation "ci_marker" does not exist after restore.

Backup test passed (only checks artifact file exists, 0.134s — does NOT verify ci_marker content)
Restore completes (test_restore_healthy passes), but ci_marker table absent from DB

Prevb-specific difference:

Run 750 upgrade: version=3.0.1+v2.0.0→3.0.1+v2.0.0 (NO-OP: UPGRADE_BASE_VERSION='3.0.1+v2.0.0' matches recipe.yml version)
Run 658 upgrade: version=d77adba4698b (git ref — genuine upgrade from published base to tested commit)
Hypothesis: prevb's new base-resolution path resolves UPGRADE_BASE_VERSION to a static version; if recipe.yml also pins that same version, the upgrade is a no-op, which may change the DB state sequence enough to break backup/restore
Same failure pattern in m2r-plausible and m2rr-plausible (prevb development runs) — both level=2, backup_restore=fail

Builder rerun: Drone 754 (triggered after 750 failed) — verdict pending.

Adversary stance: Cannot classify as flake until rerun verdict AND upgrade-version diff is understood. If 754 fails: requires Builder to diagnose no-op upgrade path + fix or explicitly suppress plausible from UPGRADE_BASE_VERSION treatment. If 754 passes: likely flake; request 3-of-3 spot-check before classifying GREEN.

Adversary closes after: rerun verdict received, root cause established, and Builder records classification decision.

A-regall-1 [adversary] CLOSED @2026-06-17T02:20Z — mailu baseline table corrected

CLOSED: Builder corrected STATUS-regall.md in commit 7c6134a: mailu upgrade rung now shows "pass" not "skip (no deployable base)".

~~### A-regall-1 [adversary] OPEN — mailu baseline table has incorrect upgrade rung~~

Filed: 2026-06-17T02:10Z Severity: LOW (informational — does not block the sweep, but affects regression classification)

Discrepancy: STATUS-regall.md baseline table shows mailu upgrade rung = "skip (no deployable base)". The actual baseline run 526 (Jun 12) shows upgrade: "pass" in both results and rungs sections.

Evidence (cold-verified from /var/lib/cc-ci-runs/526/results.json):

"results": { ..., "upgrade": "pass", ... }
"rungs": { ..., "upgrade": "pass", "backup_restore": "skip", ... }

The skip in run 526 applies to backup_restore (mailu is not backup-capable), NOT to upgrade.

Impact: If post-prevb mailu runs show upgrade=skip or upgrade=fail, it would be incorrectly considered within-baseline (the table says "skip") rather than a regression from the true baseline (upgrade=pass).

Required correction: STATUS-regall.md should read: mailu | 5 | pass | 526 for the upgrade rung.

Adversary closes: after Builder corrects the baseline table in STATUS-regall.md.

4.6 KiB Raw Blame History

BACKLOG — phase regall