chore: upgrade to 1.4.0+6.45.0-alpine #4
Reference in New Issue
Block a user
No description provided.
Delete Branch "upgrade-1.4.0+6.44.0-alpine"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Upgrade ghost: 1.3.0+6.42.0-alpine → 1.4.0+6.44.1-alpine
Image tag changes
ghost:6.42.0-alpineghost:6.44.1-alpinemysql:8.0mysql:8.4Ghost 6.42.0 → 6.44.1
No breaking changes. Incremental patch/minor releases:
MySQL 8.0 → 8.4 (LTS)
Safe LTS step (not jumping to 9.x). Live verification on cc-ci confirmed:
Operator Action Required
None. Safe incremental upgrade.
Generated by cc-ci recipe-upgrade automation.
NOT merged — for operator review.
cc @trav @notplants
!testme
🌻 cc-ci —
ghost@d42d0f7c✅ passedfull logs · dashboard
chore: upgrade to 1.4.0+6.44.0-alpineto chore: upgrade to 1.4.0+6.44.1-alpine!testme
🌻 cc-ci —
ghost@d88f5801❌ failurefull logs · dashboard
!testme
🌻 cc-ci —
ghost@d88f5801❌ failurefull logs · dashboard
!testme
🌻 cc-ci —
ghost@d88f5801❌ failurefull logs · dashboard
!testme run 3/3 — RED (upgrade tier, timing-sensitive)
Build 519 failed in the upgrade tier. Here is the diagnosis.
What failed
Root cause
The upgrade tier base-deploys ghost:6.21.2-alpine + mysql:8.0 (recipe 1.2.0), then chaos-upgrades to ghost:6.44.1-alpine + mysql:8.4. Docker Swarm updates both services simultaneously (default stop-first). During the rolling update:
update_config.monitor: 5s+failure_action: pause→ update pausedEvidence this is timing-sensitive (not a recipe regression)
d42d0f7, ghost:6.44.0 + mysql:8.4): PASS — the same base→head upgrade path (including mysql:8.0→8.4) converged successfullyOptions for the operator
!testmeon a lighter-loaded server — the upgrade path works (run 1 proves it); the failure is load-sensitiveupdate_config.monitor: 300sto theappservice in compose.yml — a robust recipe fix that gives Swarm 5 minutes to observe the new task, letting Ghost retry until MySQL finishes upgrading (also benefits production operators doing mysql:8.0→8.4 upgrades on busy servers)3-run budget exhausted
3/3 !testme runs have been used: run 1 PASS (June 5), run 2 FAIL (infrastructure IPAM, June 12), run 3 FAIL (timing, June 12). Cannot trigger a 4th run automatically. Awaiting operator decision.
Nothing was merged.
!testme
🌻 cc-ci —
ghost@d88f5801❌ failurefull logs · dashboard
!testme
🌻 cc-ci —
ghost@d88f5801✅ passedfull logs · dashboard
Post-proxy fresh run — ✅ PASS (build #612, level 5/5)
Summary: The upgrade path is sound. Prior failures on 2026-06-12 were infra-confounded, not recipe regressions.
Result
Build #612 triggered 2026-06-13T06:13Z (post-proxy fix), head
d88f5801:Level 5/5 — full logs
Why the 2026-06-12 runs failed
All four pre-proxy-fix failures (builds 515, 517, 519, 557 on 2026-06-12) occurred while:
proxyoverlay network was/24(10.0.1.0/24 — only 254 VIP slots), causing Docker Swarm IPAM pressureThe proxy network was expanded to
/16(10.10.0.0/16) at 2026-06-13T05:38Z. The fresh post-proxy run with an unloaded server succeeded cleanly at level 5/5 — confirming the upgrade path is correct and no recipe change is needed.This PR is operator-ready. Nothing was merged.
chore: upgrade to 1.4.0+6.44.1-alpineto chore: upgrade to 1.4.0+6.45.0-alpine!testme
🌻 cc-ci —
ghost@2b99b04d✅ passedfull logs · dashboard