Follow-up to 84f8fa3, fixing an over-correction that caused two live failures today.
What went wrong
84f8fa3 made branches: filters match the branch a merge-queue ref is about to become. That was right for verify and package — without it the queue's CI was strictly weaker than the branch's. But it also swept in jobs with environment: set, so deployment jobs began executing from refs/merge-queue/N. Both possible outcomes failed, and both happened:
-
Unmerged code reached production. AkurAI-Build's
deploy-productionhas no approval gate, so it ran fromrefs/merge-queue/3(run 2007) and redeployed this service from a commit that had not merged yet. The restart at 12:18:31 killed run 2008, which was executing at that instant. It recordedexit_code=nullwith a truncated log — indistinguishable from a genuine test failure, and it bounced an approved PR back toopen. -
The queue deadlocked. AkurAI-Framework's
deployis approval-gated, so run 2009 sat inwaitingindefinitely, holding its queue slot and blocking the merge on a human production-deploy approval inside what is only a merge check. Itsverifyandpackagehad both already succeeded.
Evidence of the regression, same repo, same pipeline, before and after 84f8fa3:
| Run | Ref | deploy-production |
|---|---|---|
| 2002 | refs/merge-queue/1 | skipped |
| 2007 | refs/merge-queue/3 | succeeded |
The fix
Validating a merge is not landing it. A merge-queue ref is a commit that has not merged and may never merge, so jobs declaring an environment are skipped there with a reason naming the merge queue. The post-merge default-branch run owns deployment. verify, package and every other branch-filtered job still run on the queue ref, so the gate 84f8fa3 closed stays closed.
Verification
deployment_jobs_do_not_run_on_merge_queue_refs asserts both halves — the deployment job is skipped and a non-deployment job on the same ref still succeeds — so this cannot silently re-break the branch-filter fix. I confirmed the test actually catches the defect by removing the guard and re-running: it fails with left: "succeeded", right: "skipped".
cargo fmt --all -- --check: cleancargo clippy --all-targets --all-features --locked -- -D warnings: cleancargo test --lib: 336 passed, 0 failed, 4 ignored
Note for the reviewer
This PR's own merge-queue run still executes under the currently deployed binary, so deploy-production will run from the queue ref one last time and deploy this fix. That is the existing behaviour, not a new risk; subsequent queue runs will skip it.
🤖 Generated with Claude Code
https://claude.ai/code/session_01FRtUmfFA7yWCFpX9dCaXvz