Fix maintainer-approval not blocking PRs without approval#4935
Merged
simonfaltum merged 2 commits intoApr 13, 2026
Conversation
The previous change (PR #4931) switched maintainer-approval from commit statuses to check runs. However, check runs with status "in_progress" are treated by GitHub as "still running" and don't block the required status check, so all PRs could merge without approval. Fix: for approved PRs, create a success check run (green, clickable). For pending PRs, create nothing. The required status check stays as "Expected" in GitHub (yellow dot), which blocks the merge until approval is granted. Co-authored-by: Isaac
simonfaltum
force-pushed
the
simonfaltum/fix-maintainer-approval-merge-queue
branch
from
1ab7306 to
340bb35
Compare
mihaimitrea-db
approved these changes
Apr 13, 2026
denik
pushed a commit
that referenced
this pull request
May 20, 2026
## Why PR #4931 switched `maintainer-approval` from commit statuses (`createCommitStatus`) to check runs (`checks.create`) so the check is clickable in the GitHub UI. The pending state used `status: "in_progress"`, which GitHub treats as "still running" rather than "blocking". This meant all PRs could merge without maintainer approval. ## Changes Removes the three `checks.create` calls for pending states (wildcard files, uncovered groups, no approval). When no check run or status exists for `maintainer-approval` on a SHA, GitHub shows the required check as "Expected" (yellow dot) and blocks the merge. Approved PRs still get a success check run (green, clickable). The result: - **No approval**: yellow dot, merge blocked, reviewer info in PR comment - **Approved**: green checkmark, clickable, shows who approved - **Merge queue**: green checkmark, auto-approved (unchanged) ## Test plan - [x] All 20 tests in `maintainer-approval.test.js` pass - [ ] Verify on a subsequent PR (after merge) that `maintainer-approval` shows yellow "Expected" without approval, then turns green after approval Note: the workflow uses `pull_request_target`, so it runs from main. This PR cannot test itself.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
PR #4931 switched
maintainer-approvalfrom commit statuses (createCommitStatus) to check runs (checks.create) so the check is clickable in the GitHub UI. The pending state usedstatus: "in_progress", which GitHub treats as "still running" rather than "blocking". This meant all PRs could merge without maintainer approval.Changes
Removes the three
checks.createcalls for pending states (wildcard files, uncovered groups, no approval). When no check run or status exists formaintainer-approvalon a SHA, GitHub shows the required check as "Expected" (yellow dot) and blocks the merge. Approved PRs still get a success check run (green, clickable).The result:
Test plan
maintainer-approval.test.jspassmaintainer-approvalshows yellow "Expected" without approval, then turns green after approvalNote: the workflow uses
pull_request_target, so it runs from main. This PR cannot test itself.