From ffee6732d4b1c8b09e6c625eed6efebc57f0be0b Mon Sep 17 00:00:00 2001 From: Gabriel Taveira Date: Sun, 26 Jul 2026 22:10:32 -0300 Subject: [PATCH] docs(ci): note the check-approval gate on release PRs v1.0.11 published and tagged fine, then its bump PR sat with no checks reported: GitHub held both runs as `action_required` because `github-actions[bot]` had no merged PR in the repo yet and the fork-PR approval policy was `first_time_contributors`. Auto-merge waits forever on checks that never report. Policy is now `first_time_contributors_new_to_github` and the bot has a merged PR, so it shouldn't come back. Documented anyway with the one command to clear it, since the symptom looks like a hung release rather than a permission prompt. --- .github/workflows/release.yml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 08bd092..d65bf14 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -81,6 +81,17 @@ jobs: # has to arrive as a PR. Merge commit, not squash: the tag points at the # bump commit, and squashing would rewrite it and leave the tag off # master's history, which breaks the next release's changelog range. + # + # v1.0.11 needed its two check runs approved by hand before auto-merge + # would fire. GitHub held them as `action_required` because + # `github-actions[bot]` had no merged PR here yet and the fork-PR approval + # policy was `first_time_contributors`. The policy is now + # `first_time_contributors_new_to_github` and the bot has a merged PR, so + # this shouldn't recur. If a release PR sits with no checks reported, that + # is what happened: approve the runs on the Actions tab, or + # `gh api -X POST repos/OWNER/REPO/actions/runs/RUN_ID/approve`. + # npm, the tag and the GitHub release are already out at that point, so + # only the bump on master is waiting. - name: Land the version bump on master if: ${{ !inputs.dry-run }} env: