13a951de69
Post-proxy fresh !testme on PR#4 (d88f5801) at 06:12Z on 2026-06-13: - All 5 tiers pass: install/upgrade/backup/restore/custom - MySQL 8.0→8.4 upgrade converged cleanly without load pressure - All 4 prior failures (builds 515/517/519/557) dated 2026-06-12, pre proxy-fix (05:38Z) M1: pre-proxy failures correctly classified as infra-confounded (not recipe regression) M2: PR#4 green + operator comment; PR#3 closed (superseded); PR#5 closed (cfold probe); no ghost leaks
3.6 KiB
JOURNAL — phase ghost
2026-06-13T07:10Z — Phase start, PR inventory, fresh run triggered
PR inventory findings
Three open PRs on recipe-maintainers/ghost:
-
PR#4 (d88f5801):
chore: upgrade to 1.4.0+6.44.1-alpine— the correct upgrade PR. Had 4 pre-proxy-fix failures, all on 2026-06-12. The detailed failure in build 519 showed MySQL 8.0→8.4 data-dir timing under load (Swarm UpdateStatus=paused) but the server was under unusual load at the time (IPAM fix, Docker daemon restart, multiple concurrent builds). The 3/3 budget was exhausted and then a 4th run was triggered at 21:51Z by the cfold/ghost agent, also failing (pre-proxy-fix). -
PR#5 (d42d0f7c):
ci: cfold ghost green-head probe— created by cfold/ghost agent as sweep probe to verify the old-green head separately from the current PR#4 head regression. Passed build 585 at 03:59Z on 2026-06-13 (BEFORE proxy fix at 05:38Z), so this pass was on old infra. Not the correct PR — close after M2. -
PR#3 (720faa0b):
chore: upgrade to 1.3.0+6.43.1-alpine— superseded by PR#4. Close.
Proxy fix status
docker network inspect proxy shows subnet 10.10.0.0/16 — the /16 fix is in place.
pvfix completed at 05:38Z on 2026-06-13, pvcheck completed (M1+M2 PASS).
No resource leaks
docker stack ls, docker service ls, docker volume ls — no ghost stacks or volumes.
Decision: trigger fresh post-proxy !testme on PR#4
The phase plan says "Do not count pre-proxy failures as current recipe evidence" and to run
one clean post-proxy !testme. All 4 failures on PR#4 were pre-proxy-fix.
PR#5's build 585 passed the OLD head (d42d0f7c, ghost 6.44.0) but that was also pre-proxy-fix. The upgrade path under test in PR#4 is different: upgrading to 1.4.0 (ghost 6.44.1 + mysql 8.4 from mysql 8.0 base). This is the critical path.
Why the prior failures may be infra-confounded
The diagnostic comment on PR#4 (build 519) specifically mentions "Docker daemon had just been restarted (IPAM fix), multiple concurrent builds in progress, resulting in slower MySQL startup". This is a direct load-induced timing issue, not a systematic recipe bug. The /16 proxy fix means there's no longer VIP exhaustion risk, and we're not in the middle of an IPAM repair.
However, the MySQL 8.0→8.4 data-dir upgrade timing is a real concern even without load pressure — the update_config.monitor: 5s default may genuinely be too short for the migration. The fresh run will clarify this.
2026-06-13T06:20Z — Build #612 PASSED — level 5/5
Build #612 triggered by !testme on PR#4 at 06:12:48Z, completed ~06:20Z.
Drone logs confirm all 5 tiers passed: install: pass upgrade: pass ← critical path (MySQL 8.0→8.4 data-dir migration) backup: pass restore: pass custom: pass
Level 5/5 — results.json written, summary.png + badge.svg generated.
The upgrade tier passed cleanly. This confirms the prior failures were load-induced (infra-confounded). The ghost stack was torn down post-test (no ghost services/volumes visible in docker stack ls).
Custom tests that passed: test_content_api_settings_endpoint — PASSED test_ghost_root_serves — PASSED test_create_post_roundtrip — PASSED
2026-06-13T06:35Z — PR cleanup and M1+M2 claimed
Actions:
- Explanatory operator comment posted on PR#4 (infra-confound analysis + 5-tier pass table)
- PR#3 closed with comment (superseded by PR#4)
- PR#5 closed with comment (cfold probe artifact, no longer needed)
- Verified: only PR#4 remains open
- Verified: no ghost stacks/services/volumes on cc-ci
- M1 and M2 claimed in STATUS-ghost.md