Skip to content

devops: evaluate replacing Mergify's queue with GitHub native merge queue #11204

Description

@alchemydc

Priority: P2; independent of the other CI issues
Related: #11164, #11175, #11176

Motivation

Mergify currently provides Zebra's queue eligibility, batching, urgent/batched policies, priority ordering, and merge-train implementation. Supporting its synthetic queue PRs adds workflow-specific classification, concurrency, skipped-work handling, and cancel-closed-queue-runs.yml. The evaluation baseline is the post-#11176 state (queue gates derived from the repository ruleset, PR Gate requirement dropped — #11175), which already removes part of this duplication.

GitHub's native merge queue can replace the queue/merge-train role and supports required checks on merge_group, build concurrency, merge limits, wait time, merge method, and status-check timeouts. It is not automatically a complete replacement for Zebra's current policy:

  • GitHub's documented queue is FIFO, while Zebra gives P-Critical PRs explicit Mergify priority;
  • Mergify automatically queues PRs that satisfy its conditions, while the native enrollment/auto-merge workflow must be specified;
  • current Mergify conditions restate approval, change-request, label, base, and required-check rules;
  • operational visibility and failure/requeue behavior differ.

Mergify could technically remain for unrelated PR automation, but Zebra's current Mergify file is almost entirely queue policy. If native behavior is accepted, the likely end state is removal of Mergify rather than two systems managing the same queue.

Zebra should not copy Zakura's status-checks.patch.yml. Zebra already starts each required workflow and reports a stable aggregator after internal path filtering. That avoids maintaining inverse glob lists.

Proposed evaluation

Feature and policy matrix

Compare the current and native behavior for:

  • merge method (merge);
  • maximum concurrent checks (currently 5);
  • batch minimum/maximum and two-minute wait;
  • P-Critical priority and interruption policy;
  • automatic versus manual queue enrollment;
  • required approvals and unresolved change requests;
  • do-not-merge, draft, and base-branch conditions;
  • the four required contexts: lint, unit-tests, test-crates, pr-gate-result;
  • fork PRs and secret-bearing integration workflows;
  • cancellation after source updates or queue removal;
  • failure diagnosis, requeue, and operator visibility;
  • rollback to Mergify.

Read-only/config prototype

  1. Confirm the repository ruleset can require native merge queue and the four aggregator contexts.
  2. Verify every required workflow emits the same context on pull_request and merge_group events.
  3. Exercise representative Rust, docs-only, label, release, fork, and failing-check cases in a non-production branch/ruleset or other safe test repository.
  4. Retain the current internal dorny/paths-filter plus aggregator model. Do not add an inverse-path no-op workflow.
  5. Map each Mergify-only branch in pr-gate.yml, tests-unit.yml, test-docker.yml, zfnd-deploy-nodes-gcp.yml, trigger-integration-tests.yml, and cancel-closed-queue-runs.yml to deletion or native behavior.
  6. Decide explicitly whether loss of automated P-Critical ordering is acceptable. If not, record that native queue is not currently a full replacement.
  7. Define rollback: disable the native requirement, restore/enable the validated Mergify config, and verify required contexts before reopening merges.

Acceptance criteria

  • A written feature/policy matrix covers every behavior above.
  • The prototype uses Zebra's existing aggregator/path-filter design and adds no patch workflow.
  • All four required contexts report successfully on a native merge_group test.
  • Urgent-priority and automatic-enrollment differences have an explicit team decision.
  • The document states whether Mergify is removed or retained only for named non-queue automation.
  • Rollback is tested and does not require a force-push or bypassing required checks.
  • No production migration occurs until the team records its decision.

Parent: #11197 (Evaluate and possibly retire Mergify), part of the Improve CI program (#11196)

Drafted with Claude Code from the comparative analysis and the reviewed plan; independently reviewed and corrected with OpenAI Codex. Maintainers remain responsible for validating measurements and approving coverage tradeoffs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-devopsArea: Pipelines, CI/CD and DockerfilesC-designCategory: Software design workS-needs-designStatus: Needs a design decision

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions