mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-17 12:42:21 +03:00
9fa54e85e4
* feat(ci): Mergify merge queue for release branches + manual-train fallback runbook (WS3.4/WS3.2) D5 final decision (owner, 2026-07-13, post vendor research): Mergify OSS plan — free/unlimited for the public repo, with the two features the volume demands (85-100 active authors/month, 300+ PRs/week peaks, ONE merger): batching + automatic bisection of red batches (log2(N) vs N revalidations). Proven at larger scale by NixOS/nixpkgs. - .mergify.yml: queue for base ~= release/vX.Y.Z (the wildcard GitHub's native queue cannot do); entry ONLY via the owner-applied 'queue' label AFTER the pre-merge star gate (the label IS the approval — Mergify executes, never decides); merge_conditions '#check-failure=0' + '#check-pending=0' respect the path-filtered fast-gates; squash keeps one-commit-per-PR history; label auto-removed after merge. Freeze/cross-session guardrails documented in-file. - docs/ops/MERGE_TRAIN.md (WS3.2): the manual merge-train codified as the FALLBACK runbook (batch -> validate once -> bisect halves on red) + the tiering rationale (per-PR fast-gates, per-tip continuous release-green, per-release full matrix — nothing validated less, just per batch not per PR). - 'queue' label created in the repo. Config validated (YAML parse); Mergify's own config check runs on this PR. * fix(ci): mergify queue must not fail open — require the always-on Merge-integrity check as affirmative success
3.4 KiB
3.4 KiB
title
| title |
|---|
| Merge Queue & Manual Merge-Train Runbook |
Merge Queue & Manual Merge-Train Runbook
Since v3.8.49 (WS3.2/WS3.4 of the quality/velocity plan) the default merge path for
reviewed PRs into release/vX.Y.Z is the Mergify merge queue (.mergify.yml);
the manual merge-train documented below is the FALLBACK — used during incidents,
release freezes, or if the Mergify Open Source plan ever changes.
Default path: the Mergify queue
- PR is reviewed/greened by the campaigns and approved by the owner's pre-merge ⭐
gate (the report + per-item decision — see
/merge-prsStep 0.75). - The owner (or the session acting on the owner's decision) applies the
queuelabel. The label IS the merge approval; Mergify only executes it. - Mergify batches up to 10 queued PRs, validates the batch against the fast-gates, and merges (squash). A red batch is bisected automatically — the offending PR is isolated in ~log2(N) revalidations and unqueued; the rest proceed.
- Post-merge, the continuous release-green workflow validates the new tip on push and opens an attribution issue if the combination regressed (never auto-revert).
Guardrails (mirror CLAUDE.md Hard Rules #21/#22):
- Release freeze open → do NOT label PRs targeting the frozen branch; retarget to
the active
release/vX+1first. - Another session's in-flight PR → never label it; only the owning session queues its own work.
- Tests-only diffs and
hotfix-labeled PRs already run reduced CI (seeRELEASE_CHECKLIST.md→ Hotfix Fast-Lane); the queue conditions accept whatever check set actually ran (#check-failure=0+#check-pending=0).
Fallback: the manual merge-train
Used when the queue is unavailable. This codifies the practice that drained 33 PRs in one day during the v3.8.47 cycle:
- Assemble the batch (~10–30 reviewed+approved PRs). Check
linked:collisions (sametap.testFiles, same CHANGELOG hunks) and serialize those. - Validate ONCE: in an isolated worktree off the release tip, merge all batch
heads locally, then run the release-equivalent suite
(
npm run check:release-green, add--with-buildbefore a release). - Green → merge the PRs in sequence (re-checking
state,headRefOidbefore each — a PR whose head moved re-enters review). Prove the net diff of each merge is the PR's own change (no auto-resolve reverts: auditgit diff --statfor out-of-scope deletions). - Red → bisect the batch by halves (validate each half) instead of re-validating one-by-one; drop the offending PR back to the review queue with the evidence.
- Never: merge during a freeze into the frozen branch;
git stashanywhere; blanket-rerun CI hoping a red goes away (rule: a red is information).
Tiering (why the queue is safe with fast-gates only)
- Per PR (quality.yml fast-gates): TIA-impacted tests + full unit 4-shard + vitest + lint bag + typecheck + docs/changelog integrity.
- Per batch/tip (continuous release-green):
--quickHARD gates on every push to the release branch; full--with-build --full-cisweeps 3×/day. - Per release (ci.yml on the release PR): the complete matrix incl. E2E ×9, package-artifact + tarball boot-smoke, coverage/ratchets.
Nothing is validated less than before — the heavy surface just runs per batch/tip instead of per PR, which is what removes the O(N) round-trips.