3.5 KiB
Pull-request approval policy
Summary
The weighted-approval workflow publishes an approval score for branch rules. Reviewer selection and review requests remain manual.
Table of Contents
Approval scoring
The weighted approval workflow publishes the weighted approval commit status on the pull request head. Branch rules must require this status with GitHub Actions as its expected source; a context-only requirement can accept a same-named status from another integration. The status succeeds at two approval points, remains pending below two points or while the pull request is a draft, fails while a write-capable reviewer has an effective CHANGES_REQUESTED review, and reports an error when policy evaluation fails.
Reviewers whose calculated base repository permission is write or admin count. The approval policy gives @07akioni, @imccyu, @tianyicui, @tianyicui-bot, @turtle1999, and @turtle2099 two points each; every other write-capable reviewer gets one point. The pull-request author and reviewers without write permission do not count.
Each reviewer contributes only the current APPROVED or CHANGES_REQUESTED decision that GitHub returns. A DISMISSED record clears that reviewer's standing decision, including earlier approvals. Comment-only and pending records do not replace a decision. Reviews from deleted accounts and reviewers without current repository access do not count. The workflow does not invalidate an approval by its review commit; the repository's native pull-request rules own stale-review and latest-push requirements.
The publisher runs when a pull request opens, synchronizes, reopens, becomes ready, or becomes a draft. Review submissions, edits, and dismissals run the no-permission weighted-approval-review-event workflow; its validated run title supplies the pull-request number to the default-branch publisher. The publisher validates the current head, fetches every review, and resolves current repository permission before publishing the status. Permission changes take effect on the next subscribed pull-request or review event.
Security
The status-writing job checks out only the repository default branch. It does not check out or execute pull-request code and does not use repository secrets. The review-event workflow has no GITHUB_TOKEN permissions and passes only a decimal pull-request number in its run title. The publisher rejects an invalid run title and a number that does not resolve to the workflow run's current pull-request head. Pull-request reviews are treated as API data and escaped in logs.
Approval policy changes take effect only after they merge into the default branch. This prevents an untrusted pull request from changing the program or policy for its own run.
Verification
Run pnpm run test:approval-policy for policy parsing, effective review decisions, review-event validation, pagination, permission filtering, weighted scoring, blockers, drafts, status publication, and API failures. Workflow tests pin the trusted checkout, no-permission review handoff, permissions, events, and commands. The repository gate graph runs the approval policy and workflow tests in CI.
Dev Note
None.