Two PRs can each pass CI when opened, because each was tested against an older develop, in isolation. Merging both can still break develop: neither was re-tested against the other's changes. This is the recurring "CI green at open is not correctness" class.
Expected: before a PR lands, it is re-tested against the current develop tip (plus anything ahead of it in line), and merges only if still green.
Proposal (do later): enable a Mergify merge queue. Mergify is already active on the repo (public, so free). Label-triggered opt-in, batches a few PRs per CI run, and bisects a failing batch so innocent PRs still land.
Sketch for .mergify.yml (adds to the existing backport rules):
queue_rules:
- name: develop
merge_conditions:
- check-success=lint
- check-success=frontend-build
- check-success=frontend-tests
- check-success=tests (1)
- check-success=tests (2)
- check-success=tests (3)
- check-success=tests (4)
merge_method: merge # develop takes merge commits
update_method: rebase # rebase queue branch onto develop while testing
batch_size: 3 # test up to 3 PRs in one CI run
batch_max_wait_time: 5min
checks_timeout: 45min
pull_request_rules:
- name: queue approved + labeled develop PRs
conditions:
- base=develop
- label=queue
- "#approved-reviews-by>=1"
- -conflict
- -draft
actions:
queue:
name: develop
Usage: approve a PR, add a queue label (or comment @mergifyio queue); Mergify rebases, re-tests, and merges when green.
Notes before enabling:
- If the
develop ruleset has "require branches up to date before merging", turn it off; the queue guarantees up-to-date, and both on can deadlock.
- Validate the config with Mergify's config check / dashboard first (keys match Mergify's current schema; deprecated
autoqueue / allow_inplace_checks intentionally omitted).
- Decisions open:
queue label vs auto-queue every approved PR; batch_size 3 vs 1.
Full plan/discussion: Claude Code session https://claude.ai/code/session_01CbJcFctYibnXhwEQrpnHM3
Two PRs can each pass CI when opened, because each was tested against an older
develop, in isolation. Merging both can still breakdevelop: neither was re-tested against the other's changes. This is the recurring "CI green at open is not correctness" class.Expected: before a PR lands, it is re-tested against the current
developtip (plus anything ahead of it in line), and merges only if still green.Proposal (do later): enable a Mergify merge queue. Mergify is already active on the repo (public, so free). Label-triggered opt-in, batches a few PRs per CI run, and bisects a failing batch so innocent PRs still land.
Sketch for
.mergify.yml(adds to the existing backport rules):Usage: approve a PR, add a
queuelabel (or comment@mergifyio queue); Mergify rebases, re-tests, and merges when green.Notes before enabling:
developruleset has "require branches up to date before merging", turn it off; the queue guarantees up-to-date, and both on can deadlock.autoqueue/allow_inplace_checksintentionally omitted).queuelabel vs auto-queue every approved PR;batch_size3 vs 1.Full plan/discussion: Claude Code session https://claude.ai/code/session_01CbJcFctYibnXhwEQrpnHM3