Allow only specific people or team to approve a PR

[mantzas]

Hi,

we have private repos and we are allowing other people to have write access to the repo.

We want to be able to restrict though who is allowed to approve a PR based on member or even better a team.

We want also to have at least 3 people of the owning team to give approvals before the merge.

So, in essence, we want to differentiate between contributing teams and approving teams.

I know that in Gitlab this is possible, I assume in Github also but I cannot find this setting anywhere.

Code owners are restricted to have at least one of the approvers to be an owner but we want more…

Any idea?

[ghost]

Hi @mantzas! Thanks for your question.

Through protected branch settings, you can specify a minimum number of reviews from collaborators with write or admin permissions on the repo.

You can combine this with a codeowners file to ensure that at least one member of a specific team approves changes for code that they own. However it’s not possible to require that more than one member of the team in the codeowners file approves the change.

I hope this helps!

[OddKMS]

@Alex-ley-scrub Aye for some reason I expected this functionality to already be present in GitHub since Azure DevOps often lags behind its competetors - especially considering how long GitHub has been around.

[dieter-aerit]

Just want to add in that this isn't a good answer.
I want to be able to configure that team(s) A and B need to approve a PR before it can go out.

Since nowadays a lot of process control happens through VCS, being able to enforce stakeholder approval is pretty important.

[pdefreitas]

We had on ADO similar setup to what @Alex-ley-scrub mentioned. We would like to have a similar feature.

[AwolDes]

+1 to the replies here. It is limiting in our org because we encourage people in non-technical roles (i.e Support, Product Managers) to write small PRs to update copy or even write small features. Restricting their ability to approve of PRs would be very useful, as it means an approval comes with sign off that the technical quality meets our standards. A similar use case would be team members who mostly QA & have write access for copy updates.

[bioche]

Github has added rulesets but weirdly it still doesn't handle this common use case :/

[akashdip2001]

GitHub does provide features to control code review and approvals based on teams and individuals. To achieve what you're looking for, you can use branch protection rules combined with code review assignment.

Here's a guide:

1. Teams:

   • Ensure that you have teams created on your GitHub organization that represent contributing teams and approving teams.

2. Branch Protection:

   • Go to your repository on GitHub.
   • Navigate to "Settings" > "Branches."
   • Add a branch protection rule for the branch you want to protect (e.g., master).
   • Enable "Require pull request reviews before merging."

3. Reviewers:

   • Under "Require review from Code Owners," specify the team(s) that should be responsible for code reviews.
   • Add other teams or individuals who should also review the code.

4. Required Reviewers:

   • Enable "Dismiss stale pull request approvals when new commits are pushed."
   • Set the "Required approving review" to 3 (or the number you prefer).

By configuring these settings, you can ensure that specific teams or individuals are required to review the code, and you can set the number of approvals needed before merging. Keep in mind that GitHub doesn't directly have a concept of "approvers" distinct from code owners, but you can achieve the desired workflow through the settings mentioned above.

Profile

AKASHDIP MAHAPATRA
"everything is physics bro"
E=mc²

Subscribe on YouTube

[dieter-aerit]

@akashdip2001 : But as I understand it works now, if my code owners mentions 2 groups, let's call them "contributors" and "approvers", and I require X number of approvers on the PR, then GitHub would be fine with X contributors OR X approvers giving their approval on the PR.

I want to enforce that both contributors AND approvers give their consent on the PR, and that is not possible as far as I know?

So if I require 2 reviewers, I want it to be a contributor and an approver. NOT 2 contributors or 2 approvers.

[akashdip2001]

To achieve the requirement where you want both "contributors" and "approvers" to give their consent on a pull request (PR), you can't rely on the basic 'required reviewers' functionality provided by GitHub as it does not differentiate between groups of reviewers. However, there are workarounds to impose such constraints:

1. Pull Request Templates: Use a PR template to instruct contributors that they must have approval from at least one member of each group. This is an honor system and relies on individuals adhering to the guidelines.

2. CODEOWNERS File: More granular control can be achieved by using the CODEOWNERS file. You can segment the codebase into sections and assign a required approver (or approvers) for each section. You could theoretically set this up to enforce separate approvals from contributors and approvers.

   However, enforcing a strict separation where exactly one of each must approve is still not achievable with this alone.

3. Status Checks: You can implement a custom status check using GitHub Actions or external CI/CD services. This custom script would check the list of reviewers and only pass if it includes the required mix of contributors and approvers.

4. Protected Branches with Required Status Checks: Use branch protection rules to require status checks to pass before merging. Combining this with the custom status check script from point 3 can enforce your requirement.

5. GitHub Apps or Bots: Create or use a GitHub App or a bot that can block a PR merge if the approval criteria are not met. The app would programmatically evaluate the current approvals and compare them against your criteria (one contributor and one approver).

6. Review Required Labels: Use labels and GitHub Actions to enforce that a contributor's approval adds a specific label (say, contributor-approved) and an approver's approval adds another (approver-approved). A PR can only be merged if it has both labels.

Remember, automation solutions like GitHub Actions, bots, or apps will require additional maintenance and oversight but can provide the level of control you're looking for.

While the custom automation setup might require initial investment in time and possibly infrastructure (if you don't use existing GitHub Actions or Apps), it is the most reliable way to enforce complex review policies.

[mithunpandey]

The Use case is very clear,
How to enforce that Unless one reviewer each from Multiple Teams mentioned in the CODEOWNERS file for single Pull Request approves it the PR cant be merged.

IT seems like this can not be done by using the Branch Protection settings and CODEOWNERS file

[Shreyas-Jangam]

Enable Branch Protection Rules
Go to your repository on GitHub.
Navigate to Settings > Branches > Branch protection rules.
Click on Add rule and specify the branch you want to protect (e.g., main).
Under Branch protection rules, enable Require pull request reviews before merging.
Enable Require review from Code Owners to ensure only code owners can approve.
2. Define Code Owners
In the root directory of your repository, create a .github/CODEOWNERS file (if it doesn’t exist already).
Specify the paths and the users or teams responsible. For example:
plaintext
Copy code

This makes only the specified users or team members code owners for the repository

• @username1 @username2

Or specify a team

• @org/team-name
  Save and commit the .github/CODEOWNERS file.
  With this setup, only the specified users or teams in the CODEOWNERS file can approve the PRs. This is particularly useful in repositories where approvals are required only from particular team members or domain experts.