Require PR review in branch protection rules without "write" access

Question

I have a team working in few GitHub repositories. Each repository has responsible person (maintainer) who performs final review of pull requests and merging it to master if it's OK. All other members are developers and reviewers for this repository (but may have maintainer role in another repo). The workflow is:

Member1 submits PR
Member2 reviews PR
Maintainer reviews and merges PR

To require PR review I enabled "branch protection rules" to master and checked "Require pull request reviews before merging". But when team members approves PR, it doesn't become "green" and maintainer can't merge it, to make PR approval "green" I changed team members access to "write". But now each member can merge pull requests without maintainer involvement:

Member1 submits PR
Member2 reviews PR
Member1 o Member2 merges PR (if they have write access)

Also, write access gives an ability to close tickets and pull requests. Of course, we may have verbose agreement that somebody is a maintainer and only this person can merge PRs in some particular repo, but in this case I don't see how GitHub helps with this "branch protection rule".

Is it possible to automate this workflow using GitHub configuration? I want to give only "read" permissions in each repository to developers and reviewers and "maintain" role to maintainer.

I see some possible workarounds, but it's needed to implement it manually:

Using GitHub actions: trigger GitHub action on PR approve event, check if approver is a team member and has "read" access, approve PR from action.
Use simple hosted server with a bot user: add bot user to a repo with write permission, listen for webhooks on a server, and approve PR via API using bot token on approve webhook from team member.

Maybe I missed something and I can do it without writing code but just using GitHub? It seems to be very common practice, I don't see why it's not implemented on GitHub side.

user_1110798 · Answer

The "required approving reviews" setting on GitHub protected branches only counts people who have write or admin permissions, so it seems like you're out of luck if you're wanting to count the people with read permissions.

From Approving a pull request with required reviews:

If your repository requires reviews, pull requests must have a specific number of approving reviews from people with write or admin permissions in the repository before they can be merged.

Beyond that, I think you're down to the workarounds/integrations like you suggested. Triggering a bot to approve may be an option, but if you need more than 1 additional approval then you'll probably need multiple bot accounts (bot can only approve a PR once)? You could probably tally up the reviews and leave a pass/fail status on the PR though (which could be a required status check).

If you aren't looking to build/host something, then you might take a look at PullApprove. There's more flexibility for counting reviews and "read" permissions are fine so long as they can review a PR.

A basic PullApprove configuration would look more like this:

# .pullapprove.yml
version: 3

groups:
  members:
    reviewers:
      teams: [members-team]
    reviews:
      required: 1
      request: 1
  maintainer:
    reviewers:
      users: [maintainer-jeff]
    required: 1
    request: 1

And then could be set as a required status (with or without an additional GitHub minimum of 1 approval):

Require PR review in branch protection rules without "write" access

1 Answers