Mergify Phase 1 (#409 / #412) is merged and active, but it is NOT auto-embarking PRs into the queue. Over multiple checks: the Mergify Merge Queue and Mergify Merge Protections checks read COMPLETED/NEUTRAL (not embarked) even on PRs with a green CI passed (#397, #400). Zero PRs have merged via Mergify. The known GitHub native auto-merge flow still works and is being used to drain the cascade; Mergify's checks are non-blocking (they merge fine).
Why it wasn't debugged overnight
Diagnosing embark-eligibility needs the Mergify dashboard (shows per-PR why not queued) — not visible via gh. And the open PRs have interlocking jacocoNonJvmTestableSurface conflicts, so a blind "disable native auto-merge to test" risks stranding a PR. Left for daytime + dashboard access.
Hypotheses (ranked) to check on the dashboard
Mergify defers to GitHub native auto-merge when it's armed on a PR — ALL open PRs have native auto-merge on; Mergify may not embark until it's off. Test: disable native auto-merge on ONE clean (non-conflicting) green PR and watch if Mergify embarks it.
The pull_request_rulesqueue action needs a tweak (schema/trigger) — the dashboard will name the failing condition.
Mergify app/queue not fully enabled in the org/repo dashboard settings.
Go-live (do once embark is verified)
Confirm Mergify embarks+updates+merges ONE PR correctly, THEN the switchover: disable GitHub native auto-merge on the open PRs so Mergify solely owns them. Escape hatch: revert #412 (.mergify.yml) -> Mergify inert -> known flow (not needed now — nothing blocked). Relates #409/#412/#410.
## Observed (overnight 2026-07-07)
Mergify Phase 1 (#409 / #412) is **merged and active**, but it is **NOT auto-embarking PRs** into the queue. Over multiple checks: the `Mergify Merge Queue` and `Mergify Merge Protections` checks read `COMPLETED/NEUTRAL` (not embarked) even on PRs with a green `CI passed` (#397, #400). **Zero PRs have merged via Mergify.** The known **GitHub native auto-merge** flow still works and is being used to drain the cascade; Mergify's checks are non-blocking (they merge fine).
## Why it wasn't debugged overnight
Diagnosing embark-eligibility needs the **Mergify dashboard** (shows per-PR *why not queued*) — not visible via `gh`. And the open PRs have interlocking `jacocoNonJvmTestableSurface` conflicts, so a blind "disable native auto-merge to test" risks stranding a PR. Left for daytime + dashboard access.
## Hypotheses (ranked) to check on the dashboard
1. **Mergify defers to GitHub native auto-merge** when it's armed on a PR — ALL open PRs have native auto-merge on; Mergify may not embark until it's off. Test: disable native auto-merge on ONE clean (non-conflicting) green PR and watch if Mergify embarks it.
2. The `pull_request_rules` `queue` action needs a tweak (schema/trigger) — the dashboard will name the failing condition.
3. Mergify app/queue not fully enabled in the org/repo dashboard settings.
## Go-live (do once embark is verified)
Confirm Mergify embarks+updates+merges ONE PR correctly, THEN the switchover: disable GitHub native auto-merge on the open PRs so Mergify solely owns them. **Escape hatch:** revert #412 (`.mergify.yml`) -> Mergify inert -> known flow (not needed now — nothing blocked). Relates #409/#412/#410.
Overnight update — likely the fix: Mergify auto-opened #414 (mergify/configuration-deprecated-update, author app/mergify, title "upgrade configuration to current format"). Its diff adds allow_checks_interruption: true to each priority_rules entry — a safe Mergify-recommended format upgrade.
This is probably why it is not embarking: Mergify commonly declines to embark PRs while the .mergify.yml is on a deprecated/old format, and it opens exactly this kind of self-update PR.
Recommended morning sequence:
Review + merge #414 (it is Mergify's own upgrade — low risk; re-read the diff).
Watch whether Mergify then starts embarking a green PR (e.g. it should pick up the highest-priority mergeable one).
If it still does not embark, fall back to hypothesis #1 (native-auto-merge deferral) — disable native auto-merge on ONE clean green PR and observe — using the Mergify dashboard to see the per-PR "why not queued" reason.
Once an embark is verified, do the switchover.
Left #414unmerged overnight per the go-live deferral — it is a merge-process config change and should land under your eye. The known GitHub-auto-merge flow kept draining the cascade meanwhile.
**Overnight update — likely the fix:** Mergify auto-opened **#414** (`mergify/configuration-deprecated-update`, author `app/mergify`, title "upgrade configuration to current format"). Its diff adds `allow_checks_interruption: true` to each `priority_rules` entry — a safe Mergify-recommended format upgrade.
**This is probably why it is not embarking:** Mergify commonly declines to embark PRs while the `.mergify.yml` is on a deprecated/old format, and it opens exactly this kind of self-update PR.
**Recommended morning sequence:**
1. Review + merge **#414** (it is Mergify's own upgrade — low risk; re-read the diff).
2. Watch whether Mergify then starts embarking a green PR (e.g. it should pick up the highest-priority mergeable one).
3. If it still does not embark, fall back to hypothesis #1 (native-auto-merge deferral) — disable native auto-merge on ONE clean green PR and observe — using the Mergify dashboard to see the per-PR "why not queued" reason.
4. Once an embark is verified, do the switchover.
Left #414 **unmerged overnight** per the go-live deferral — it is a merge-process config change and should land under your eye. The known GitHub-auto-merge flow kept draining the cascade meanwhile.
#406 was made a clean candidate: GREEN (CI passed = SUCCESS, 10/10 E2E), up-to-date, GitHub native auto-merge DISARMED, matching ALL queue-action conditions (base=main, -draft, -conflict, label != broken, check-success = CI passed). Mergify's Merge Queue check stayed NEUTRAL — it did not embark it, with no GitHub auto-merge to race and after a grace period.
Conclusion — rules out the earlier hypotheses:
Config-format was NOT it (#414 merged, still no embark).
GitHub-auto-merge preemption is NOT it (disarmed PR still not embarked).
The .mergify.yml on main is present + well-formed (verified).
→ Genuine Mergify-side issue, diagnosable only on the dashboard. Please check dashboard.mergify.com for JMR-dev/LibreMail:
Is the Mergify GitHub App installed + granted access to this repo?
Is the merge queue enabled in the repo's Mergify settings?
Any config error or per-PR 'why not queued' reason in the event log for #406?
Do NOT do the switchover (disabling GitHub native auto-merge) until resolved — Mergify isn't merging, so disabling native auto-merge would strand all PRs. The GitHub-auto-merge flow keeps working meanwhile.
## DEFINITIVE embark test (2026-07-07)
#406 was made a **clean candidate**: GREEN (`CI passed` = SUCCESS, 10/10 E2E), up-to-date, **GitHub native auto-merge DISARMED**, matching ALL `queue`-action conditions (base=main, -draft, -conflict, label != broken, check-success = CI passed). Mergify's **Merge Queue check stayed `NEUTRAL`** — it did **not** embark it, with no GitHub auto-merge to race and after a grace period.
**Conclusion — rules out the earlier hypotheses:**
- Config-format was NOT it (#414 merged, still no embark).
- GitHub-auto-merge preemption is NOT it (disarmed PR still not embarked).
- The `.mergify.yml` on main is present + well-formed (verified).
→ **Genuine Mergify-side issue, diagnosable only on the dashboard.** Please check **dashboard.mergify.com** for `JMR-dev/LibreMail`:
1. Is the **Mergify GitHub App installed + granted access** to this repo?
2. Is the **merge queue enabled** in the repo's Mergify settings?
3. Any **config error** or per-PR **'why not queued'** reason in the event log for #406?
**Do NOT do the switchover** (disabling GitHub native auto-merge) until resolved — Mergify isn't merging, so disabling native auto-merge would **strand all PRs**. The GitHub-auto-merge flow keeps working meanwhile.
Root cause: the Phase-1 config auto-queued via the deprecated pull_request_rules → queue action, which no longer auto-embarks (a matched PR just reported "Merge queue is ready — use @Mergifyio queue" and sat). Modern auto-queueing lives in merge_protections_settings.auto_merge_conditions.
Fix (#422): migrated to auto_merge_conditions, plus the three in-place-checks requirements GitHub's strict required_status_checks ruleset demands — merge_queue.max_parallel_checks: 1, every queue_rules[].batch_size: 1, and queue_conditions identical to merge_conditions.
Proof: PR #425 went green, auto-embarked into the Mergify Merge Queue with no manual arming, was validated in place against latest main, and merged (mergedBy mergify[bot], Merge Queue check = pass) at 2026-07-08 03:06 UTC. Phase 1 (serial, require-up-to-date preserved) is live.
Resolved and proven live.
**Root cause:** the Phase-1 config auto-queued via the deprecated `pull_request_rules` → `queue` action, which no longer auto-embarks (a matched PR just reported "Merge queue is ready — use `@Mergifyio queue`" and sat). Modern auto-queueing lives in `merge_protections_settings.auto_merge_conditions`.
**Fix (#422):** migrated to `auto_merge_conditions`, plus the three in-place-checks requirements GitHub's strict `required_status_checks` ruleset demands — `merge_queue.max_parallel_checks: 1`, every `queue_rules[].batch_size: 1`, and `queue_conditions` identical to `merge_conditions`.
**Proof:** PR #425 went green, auto-embarked into the Mergify Merge Queue with no manual arming, was validated in place against latest `main`, and merged (mergedBy `mergify[bot]`, Merge Queue check = pass) at 2026-07-08 03:06 UTC. Phase 1 (serial, require-up-to-date preserved) is live.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Observed (overnight 2026-07-07)
Mergify Phase 1 (#409 / #412) is merged and active, but it is NOT auto-embarking PRs into the queue. Over multiple checks: the
Mergify Merge QueueandMergify Merge Protectionschecks readCOMPLETED/NEUTRAL(not embarked) even on PRs with a greenCI passed(#397, #400). Zero PRs have merged via Mergify. The known GitHub native auto-merge flow still works and is being used to drain the cascade; Mergify's checks are non-blocking (they merge fine).Why it wasn't debugged overnight
Diagnosing embark-eligibility needs the Mergify dashboard (shows per-PR why not queued) — not visible via
gh. And the open PRs have interlockingjacocoNonJvmTestableSurfaceconflicts, so a blind "disable native auto-merge to test" risks stranding a PR. Left for daytime + dashboard access.Hypotheses (ranked) to check on the dashboard
pull_request_rulesqueueaction needs a tweak (schema/trigger) — the dashboard will name the failing condition.Go-live (do once embark is verified)
Confirm Mergify embarks+updates+merges ONE PR correctly, THEN the switchover: disable GitHub native auto-merge on the open PRs so Mergify solely owns them. Escape hatch: revert #412 (
.mergify.yml) -> Mergify inert -> known flow (not needed now — nothing blocked). Relates #409/#412/#410.Overnight update — likely the fix: Mergify auto-opened #414 (
mergify/configuration-deprecated-update, authorapp/mergify, title "upgrade configuration to current format"). Its diff addsallow_checks_interruption: trueto eachpriority_rulesentry — a safe Mergify-recommended format upgrade.This is probably why it is not embarking: Mergify commonly declines to embark PRs while the
.mergify.ymlis on a deprecated/old format, and it opens exactly this kind of self-update PR.Recommended morning sequence:
Left #414 unmerged overnight per the go-live deferral — it is a merge-process config change and should land under your eye. The known GitHub-auto-merge flow kept draining the cascade meanwhile.
DEFINITIVE embark test (2026-07-07)
#406 was made a clean candidate: GREEN (
CI passed= SUCCESS, 10/10 E2E), up-to-date, GitHub native auto-merge DISARMED, matching ALLqueue-action conditions (base=main, -draft, -conflict, label != broken, check-success = CI passed). Mergify's Merge Queue check stayedNEUTRAL— it did not embark it, with no GitHub auto-merge to race and after a grace period.Conclusion — rules out the earlier hypotheses:
.mergify.ymlon main is present + well-formed (verified).→ Genuine Mergify-side issue, diagnosable only on the dashboard. Please check dashboard.mergify.com for
JMR-dev/LibreMail:Do NOT do the switchover (disabling GitHub native auto-merge) until resolved — Mergify isn't merging, so disabling native auto-merge would strand all PRs. The GitHub-auto-merge flow keeps working meanwhile.
Resolved and proven live.
Root cause: the Phase-1 config auto-queued via the deprecated
pull_request_rules→queueaction, which no longer auto-embarks (a matched PR just reported "Merge queue is ready — use@Mergifyio queue" and sat). Modern auto-queueing lives inmerge_protections_settings.auto_merge_conditions.Fix (#422): migrated to
auto_merge_conditions, plus the three in-place-checks requirements GitHub's strictrequired_status_checksruleset demands —merge_queue.max_parallel_checks: 1, everyqueue_rules[].batch_size: 1, andqueue_conditionsidentical tomerge_conditions.Proof: PR #425 went green, auto-embarked into the Mergify Merge Queue with no manual arming, was validated in place against latest
main, and merged (mergedBymergify[bot], Merge Queue check = pass) at 2026-07-08 03:06 UTC. Phase 1 (serial, require-up-to-date preserved) is live.