-
Run operations QA on every release candidate before the prod gate (#90)
All checks were successfulRelease / Build release images and notes (push) Successful in 1m8sCD / Build and push images (push) Successful in 1m9sCD / Deploy to Test (push) Successful in 9sRelease / Release-candidate operations QA (push) Successful in 41sCD / Smoke tests against Test (push) Successful in 1m10sCD / Promote to Int (push) Successful in 10sProd deploy / Deploy the released images to Prod (push) Successful in 15sCI / Lint, typecheck, test (push) Successful in 3m35sCI / Build container images (push) Has been skippedCI / Auth e2e pack (push) Successful in 5m32sCI / Import/export fidelity gate (push) Successful in 48sreleased this
2026-07-12 00:29:53 +02:00 | 220 commits to main since this releaseNew deploy/release-qa.sh, wired as the release workflow's second job: it
boots the PREVIOUS release with pre-seeded fixture content in a scratch
environment, swaps the api to the candidate against the same database
(migrations auto-apply, readiness green, content intact — the
seed_fixture/assert_fixture pair is the update-fixture contract future
migrations extend), asserts the degraded-readyz semantics on the
candidate (200 + warn-level checks without sidecars), and runs a full
backup/restore roundtrip with the candidate's sidecar into a second,
empty database. The wizard e2e already guards fresh installs in CI
(issue #81). Verified green on the host for v0.1.0→v0.1.1; a simulated
destructive migration made the suite fail loudly (negative test,
not committed). A human pushes the prod tag only when both release jobs
are green — the documented pre-approval gate.Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01EwZ4jR4KFAPvpjWevfUGX1Downloads