JMR-devandClaude Opus 4.8
0307df88a1
Investigate Mergify (free-for-OSS merge queue + batching + speculative checks) as the right-way replacement for the hand-rolled traffic-controller (autoupdate.yml + ci-trigger.yml + mothballed traffic-control.yml) and the manual serial-bump grind, now that GitHub's native merge queue is org-only and unavailable to a user account. Proposal only — NO live .mergify.yml, nothing activates: - docs/ci/mergify-integration-spec.md: how the queue coexists with the single `CI passed` gate; the require-up-to-date x merge-commits x batching trilemma and its resolution (Phase 1 serial keeps the rule literally; Phase 2 merge-batch moves the up-to-date GUARANTEE into the queue); P0-P9 -> priority_rules mapping; what it replaces; interaction with path-filter/sharding/wedge-diag; risks; phased adopt recommendation. - docs/ci/mergify.yml.proposed: annotated, NOT-active proposed config. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
117 lines
5.5 KiB
Plaintext
117 lines
5.5 KiB
Plaintext
# SPDX-License-Identifier: GPL-3.0-or-later
|
||
#
|
||
# ============================================================================
|
||
# PROPOSED — NOT ACTIVE. This is docs/ci/mergify.yml.proposed, a review
|
||
# artifact for issue #407. It is deliberately NOT committed as a live
|
||
# `.mergify.yml` at the repo root, so Mergify does NOTHING until a maintainer
|
||
# (a) installs the Mergify GitHub App and (b) moves/renames this file to
|
||
# `.mergify.yml`. Read docs/ci/mergify-integration-spec.md first — especially
|
||
# the require-up-to-date trilemma — before adopting.
|
||
# ============================================================================
|
||
#
|
||
# Schema: https://docs.mergify.com/configuration/file-format/ (validated against
|
||
# https://docs.mergify.com/mergify-configuration-schema.json on push once live).
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# queue_rules — how a queued PR is validated and merged.
|
||
# ---------------------------------------------------------------------------
|
||
queue_rules:
|
||
- name: default
|
||
# ---- Final merge gate --------------------------------------------------
|
||
# Merge only when the SINGLE aggregating required context is green — the exact
|
||
# same check branch protection already requires — plus review + not-draft.
|
||
# "CI passed" is the name: field of the `ci-passed` job in .github/workflows/ci.yml.
|
||
merge_conditions:
|
||
- check-success = CI passed
|
||
- "#approved-reviews-by >= 1"
|
||
- -draft
|
||
- label != broken
|
||
# ---- Speculative validation on top of the latest main ------------------
|
||
# Mergify builds a temporary batch branch = (latest main + the next PRs) and runs
|
||
# CI on THAT, so what merges was tested against an up-to-date base. This is the
|
||
# up-to-date GUARANTEE, enforced by the queue instead of by a stale-branch re-push.
|
||
#
|
||
# PHASE 1 (safe, keeps GitHub "require branches up to date" literally ON):
|
||
# set batch_size: 1 and merge_method: merge below, and comment out the Phase-2
|
||
# block. Serial queue = automates the manual bumping, NO batching throughput win.
|
||
#
|
||
# PHASE 2 (the throughput win — REQUIRES the maintainer decision in the spec,
|
||
# §"The require-up-to-date trilemma"): batch N PRs into ONE CI run. Batching is
|
||
# incompatible with GitHub's literal "require branches up to date" checkbox
|
||
# (Mergify docs), so that checkbox must be turned OFF and its guarantee moved
|
||
# into this queue — OR use queue_branch_merge_method: fast-forward to keep the
|
||
# checkbox at the cost of linear history (breaks the merge-commit policy).
|
||
batch_size: # dynamic: stays at min when runners are free, grows toward max on a backlog
|
||
min: 1
|
||
max: 5 # cap for the test-only batches (e.g. the #373 Robolectric epic: ~6 PRs -> ~1 run)
|
||
batch_max_wait_time: 5 min # how long to accumulate a partial batch before validating it
|
||
# One MERGE COMMIT per batch via the GitHub merge API — preserves the repo's
|
||
# merge-commit policy (never squash/rebase) at the batch granularity.
|
||
merge_method: merge-batch
|
||
# Slow + wedge-prone E2E matrix: bound the wait so a wedged emulator leg times the
|
||
# batch out (then Mergify bisects/splits it) instead of blocking the queue forever.
|
||
checks_timeout: 45 min
|
||
# How many speculative batches validate in parallel. This is the Mergify equivalent
|
||
# of the traffic-controller's MAX_INFLIGHT_RUNS (was 2). Each parallel check fans out
|
||
# to the full E2E matrix, so keep it modest against the runner budget.
|
||
# (Set under `merge_queue:` — see below — in current schema; kept here for context.)
|
||
|
||
# max_parallel_checks lives under the top-level merge_queue options.
|
||
merge_queue:
|
||
max_parallel_checks: 2 # == old MAX_INFLIGHT_RUNS; raise for throughput vs runner cost
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# priority_rules — map the repo's P0–P9 labels onto queue priority.
|
||
# Higher number merges first (Mergify: low=1000, medium=2000, high=3000; range 1–10000).
|
||
# Unlabelled PRs get Mergify's default `medium` (2000) — equivalent to the old P5 default
|
||
# in traffic_control.py. P0 is emergency-only and outranks everything.
|
||
# ---------------------------------------------------------------------------
|
||
priority_rules:
|
||
- name: p0-emergency
|
||
conditions: [label = P0]
|
||
priority: 10000
|
||
- name: p1
|
||
conditions: [label = P1]
|
||
priority: 9000
|
||
- name: p2
|
||
conditions: [label = P2]
|
||
priority: 8000
|
||
- name: p3
|
||
conditions: [label = P3]
|
||
priority: 7000
|
||
- name: p4
|
||
conditions: [label = P4]
|
||
priority: 6000
|
||
- name: p5
|
||
conditions: [label = P5]
|
||
priority: 5000
|
||
- name: p6
|
||
conditions: [label = P6]
|
||
priority: 4000
|
||
- name: p7
|
||
conditions: [label = P7]
|
||
priority: 3000
|
||
- name: p8
|
||
conditions: [label = P8]
|
||
priority: 2000
|
||
- name: p9
|
||
conditions: [label = P9]
|
||
priority: 1000
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# pull_request_rules — WHICH PRs enter the queue (the `queue` action).
|
||
# A maintainer opts a PR in by getting it green + approved (or by comment
|
||
# `@mergifyio queue`). `broken`/`draft` PRs are never queued.
|
||
# ---------------------------------------------------------------------------
|
||
pull_request_rules:
|
||
- name: Queue green, approved, non-draft PRs targeting main
|
||
conditions:
|
||
- base = main
|
||
- -draft
|
||
- label != broken
|
||
- "#approved-reviews-by >= 1"
|
||
- check-success = CI passed
|
||
actions:
|
||
queue:
|
||
name: default
|