fix(ci): gate cloud-cf-deploy on db migrations before code goes live - #11289
Conversation
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Maintainer review (deploy pipeline): approved with one pushed hardening commit. Verified the gate table trigger-by-trigger — every deploy job needs migrate-db with fail-closed semantics, the ONE allowed skip (PR previews, migrate-db skipped, staging-API frontend builds) is correctly scoped via !cancelled() + result=='skipped', and the cross-workflow serialization group matches on both sides (inline ternary here == determine-env output in cloud-deploy-backend, both yielding cloud-db-migrate-{production,staging}). The missing-secret fail-fast closes the silent-skip landmine class. Pushed: the new migrate-db job used bun canary — the exact regression class #11235 just pinned the sibling jobs off after it stranded two prod deploys; pinned to latest with the same rationale. This directly fixes the skew window we lived through on the #11150 promote (Worker deploying for 2h while migrate-db starved). Merging. |
…deploy job (#10839) (#11318) #11289's new migrate-db job — the schema gate every deploy now depends on — was the one job left on bun canary after #11235 pinned the rest of this workflow following the link-phase hang that stranded two prod deploys (runs 28552075615, 28569068598). A canary regression in the gate would fail-closed-block every deploy. Co-authored-by: moon <thefutureisaweirdplace@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
Closes #11208.
The gap
Prod refreshes via a
workflow_dispatchofcloud-cf-deploy.yml(Worker + both Pages projects), but themigrate-dbjob lived only incloud-deploy-backend.yml. The two were fully decoupled: a prod refresh shipped new code against whatever schema prod happened to have — thereview_status-outage class, primed for launch day. This implements fix option (a) from the issue: migrations run insidecloud-cf-deploy.yml, before any code goes live, fail-closed.Job graph
Before (
cloud-cf-deploy.yml— three root jobs, zero migration steps):After:
Ordering guarantee (traced per trigger)
!cancelled())db:cloud:migrate(migrate-with-diagnostics.ts) is journal-based — zero pending migrations logs[db:migrate] pending migrations: 0and exits 0, satisfying the gate.needs.migrate-db.result == 'success'for non-PR events; there is noalways()-style bypass to a deploy step.cloud-deploy-backend.yml. Bothmigrate-dbjobs now share a repo-wide job-level concurrency groupcloud-db-migrate-<env>(cancel-in-progress: false), so the migrator never runs concurrently against the same database. At most 2 jobs can ever occupy a group (each workflow already serializes itself per-ref), so the queued job is never superseded-cancelled — no reintroduction of the G3 perma-cancel pattern.ubuntu-latestdeliberately (mirrors cloud-deploy-backend) so migrations don't inherit the shared self-hosted fleet's failure modes.Verification
actionlint 1.7.12→ exit 0 on both modified workflows.needs:ref and badneeds.*expression, proving the linter exercises exactly the constructs this PR touches.needs: migrate-dbon all three deploy jobs.migrate-dbuses theproductionGitHub environment on prod dispatches, so any environment protection rules (required reviewers) now also gate the prod refresh — same behaviorcloud-deploy-backendmigrations already have.