Repository navigation
Required approvals check fails on pull requests from forks #56
Description
@martin-helmich approving #51 made the check fail — not because of the
approvals, but because the workflow could not publish its result:
POST .../check-runs → 403 Resource not accessible by integration
Run 34500498175.
The counting worked fine (2 / 1 approvals).
Cause: on a fork PR the GITHUB_TOKEN of a pull_request_review run is
read-only, so checks: write has no effect. pull_request_target runs are
fine — which is why only fork PRs are hit, and only once someone reviews them.
The comment in check-approvals.yml assumes the opposite.
Effect: on fork PRs the Required approvals status silently stops updating
and the job turns red, making the PR look blocked when it is not.
Fix options:
- Let the job itself fail instead of publishing a check run — no write token
needed at all. Branch protection would requireAssert required approvals
instead ofRequired approvals. - Publish from a
workflow_runjob, which always gets a write token.
Unrelated, same run: actions/github-script@v7 warns that Node 20 is
deprecated. Harmless, and v9 is out, but it does not cause the 403.
Reporting rather than fixing, since the workflow says non-maintenance changes
need a Board decision.
Activity
dkd-dobberkau commentedon Sep 28, 2026
Still happening, and #57 shows the practical cost. Same signature as your report: fork PR (
rfoucard/Policy),pull_request_reviewrun, counting fine, publishing 403.My approval today produced run 36411750494. The job log contains the finished request body:
followed by
Unhandled error: HttpError: Resource not accessible by integration. The visibleRequired approvalscheck is therefore still the one from the last push at 10:17:58Z, saying0 / 2.All eight
pull_request_reviewruns on #57 today failed this way — six of them from plain comment replies, two from actual reviews. The only successful run was thepull_request_targetone triggered by the push.What makes it more awkward than on #51: #57 is a
type: formal changeneeding 2 approvals, so the stale check will stay red until the second approval and a subsequentpull_request_targetevent. Anyone reading the checks in between sees0 / 2on a PR that actually has approvals, which is exactly backwards for a governance signal.No opinion from me on option 1 vs. option 2 — but since the workflow is governed by the 2026-07-09 Policy Governance decision, whichever is chosen probably needs a Board decision record, and it would be good to have it before the next formal change lands.