From 3e44e3e1378c7e3b8b259ac112451c8fe8000f66 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 14 Aug 2026 19:49:30 +0000 Subject: [PATCH] Revert "ci: block merge while checks are still running" `#check-pending = 0` deadlocks merge protections, as the comment it removed said it would. Confirmed on #946: after all 91 checks completed, Mergify sat pending with Waiting for: [ ] #check-pending = 0 Waiting checks: `` <- empty The only pending check is Mergify's own, which it cannot name. Branch protection requires that check, so nothing can merge until this is reverted. Reopens #943. The fix is pr-monitor (Option B), not a condition tweak. --- .mergify.yml | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/.mergify.yml b/.mergify.yml index 6665d05e5..cbc44d2ef 100644 --- a/.mergify.yml +++ b/.mergify.yml @@ -13,10 +13,14 @@ merge_protections: if: - base = main success_conditions: - # Names no checks deliberately: a path-filtered workflow that does not run - # reports nothing, so an anchor naming it would pend forever. + # Do NOT add `#check-pending = 0`: merge protections count their own + # in-progress check, so the total never reaches zero and the gate + # deadlocks. Confirmed on #946 -- Mergify sat pending with an empty + # "waiting checks" list after every other check had finished. + # + # The cost is that this condition is vacuously true before CI starts, + # so the gate goes green while checks are still running (#943). - "#check-failure = 0" - - "#check-pending = 0" pull_request_rules: - name: Auto-merge labelled PRs once every check is green