I am the author of the code and I am also part of code owners group list(one of the member).
If any possible way to stop reviewing my code by myself. Because I am the author and supposed to not review the code.
Any rules can i implement to stop doing review
First, you need to make sure that you have a branch protection rule defined for the branch the PR is going to be targeting.
Docs: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule
Once there, you will need to make sure you have at least the following checked off:
Require a pull request before merging
Require approvals (defaults to 1)
Require review from Code Owners
Do not allow bypassing the above settings
The last setting is the key for this to work correctly. This will require all users to adhere to the rule. Without it, admins and owners of the repo will be allowed to bypass the rule. Some organizations allow for this to prevent emergency fixes from getting blocked by "red tape".
Related
Upon reviewing the branch protection settings for a GitHub repo, and reading the documentation for all of the settings, I still can't quite figure out the difference between enabling these two groups of settings:
According to the documentation, if I require approvals, it means an approval is required from someone else (I cannot approve my own PR):
If you enable required reviews, collaborators can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions.
The next option seems self explanatory, but here is what the documentation has to say about it:
Optionally, you can choose to dismiss stale pull request approvals when commits are pushed. If anyone pushes a commit that modifies code to an approved pull request, the approval will be dismissed, and the pull request cannot be merged. This doesn't apply if the collaborator pushes commits that don't modify code, like merging the base branch into the pull request's branch.
However, when I look at the documentation for the branch protection setting to "require approval of the most recent push", it sounds like it does the same thing as if I had the first two enabled:
Optionally, you can require approvals from someone other than the last person to push to a branch before a pull request can be merged. This ensures more than one person sees pull requests in their final state before they are merged into a protected branch. If you enable this feature, the most recent user to push their changes will need an approval regardless of the required approvals branch protection. Users who have already reviewed a pull request can reapprove after the most recent push to meet this requirement.
It sounds like this option implies that an approval will be dismissed if a new commit is pushed to the branch for the open PR. If that's the case, then isn't enabling the first to the same as enabling the last one?
The "require approval of the most recent push" protection rule was recently introduced (oct 2022), with the express purpose to prevent someone responding to a code review request from sneaking in changes and approving them themselves or using the already supplied approval from another reviewer.
The security research that explores these topics has not been broadly published, but there are some great discussions with recommendations on how to secure your branches.
With this new policy enabled, when a reviewer applies some suggestions to the code, they can't approve and merge the code without finding another person to review their changes.
Excerpts from the article, red team, emphasis mine:
— Modify code after review
After the attacker submits a valid and good code change that is approved, the attacker abuses their existing approval to make further changes that include bad code while retaining the stale approval.
Another scenario is that the attacker could first be a good samaritan and approve the code of a fellow developer, let’s assume it’s a good code change, but it doesn’t matter. What matters is that once they have approved that pull request, they could abuse their own write access, add bad code and self-approve their own code change.
And the protections, blue team, emphasis mine:
Require a pull request before merging
Require approvals
Dismiss stale pull request approvals when new commits are pushed
Require review from Code Owners
Allow specified actors to bypass required pull requests (avoid unless you absolutely need to)
Require approval of the most recent push (this is a new setting, as of October 2022, and is really great mitigation for some of our attack scenarios)
Require status checks to pass before merging (it you have some form of CI with tests, linters, SAST, it would be great to enforce those)
Require signed commits (this is great for end-to-end accountability)
Enforce Branch Protection for administrator (i.e. “Do not allow bypassing the above settings”)
Recommended mitigations, emphasis mine:
— Modify code after review
Attacker submits good code, gets approval, then submits bad code
The mitigation is to set your Branch Protection to “Dismiss stale pull request approvals when new commits are pushed”.
Attacker approves someone else’s good code, then submits bad code and self-approves changes
The mitigation is to set your Branch Protection to “Require approval of the most recent push”.
This is what I know so far from my understanding of Github:
Github allows default reviewers whether it be for a specific type of file in any/certain location through the creation of the CODEOWNERS file.
Github allows the number of reviewers that are required to approve a PR. You can also specify what type of access they have.
Github allows required review from Code Owners
What I want to know is if there is a way to set up mandatory reviewers meaning that the PR can't get merged until certain people give their approval.
For example, I created a PR and I have reviewers A, B, C, D, E, and F. I want to make it so that this PR cannot get merged until reviewers A and B have approved it. I thought I could use the Require review from Code Owners but I think that it only requires at least one person to approve. The other idea that came to mind was just setting the required approval to the same number of people inside the code owners. Any help would be much appreciated.
I thought I could use the Require review from Code Owners but I think that it only requires at least one person to approve.
Your assumption is right. Currently, you can request multiple owners to review a PR, but only one of the reviews will be mandatory.
You can check the accepted answer in this GitHub Community discussion for more details.
As for the second part of your question,
setting the required approval to the same number of people inside the code owners
I believe that should do the trick. You may also want to follow the tip, described in the Approving a pull request with required reviews and ensure that code owners are the only persons with write permissions to the repo so that no other persons or groups will mess up the review process:
If your repository requires approving reviews from people with write or admin permissions, then any approvals from people with these permissions are denoted with a green check mark, and approvals from people without these permissions have a gray check mark. Approvals with a gray check mark do not affect whether the pull request can be merged.
I have an issue, I have a team (they are added into Github package's teams list with Write perm) of external developers, I want to restrict their ability to approve each other's PRs.
Meaning other team/users should be probably a different set of perms.
How can I do it? I wasn't able to find this on Github.
PS.
I tried adding this to .github/CODEOWNERS (also enabled require owner review)
* #company/company-devs some-special-developer
but #other_company/devs <- were still able to approve
Is there anyway in Azure DevOps to forbid people from adding/removing required reviewers when creating a Pull Request?
I have set up the policy "Automatically included reviewers" with a bunch of required reviewers.
But still anyone who create a PR can easily add someone else in the required reviewer list or remove anybody from the automatically included required reviewer.
I want anyone to create a PR but not add/remove any required reviewer.
Apparently this is not possible, and they don't seem to consider it a bug. See this feedback item. I think it is ridiculous that they don't consider this a bug. When you set a branch policy stating: Pull requests to this branch van only be completed when these reviewers have reviewed it, only people having the permission Bypass policies when completing pull requests should be able to complete the pull request without adhering to the policies, which includes the required reviewers policy.
I've added a new feedback item to stress this. Feel free to update this feedback item, however history tells me they will either acknowledge the issue and never fix it, or still deny it is a bug.
We probably will we have to learn to live with this bug
If a required reviewer is added via Automatically included reviewers, the reviewer can't be removed:
For reviewers added manually or via the API there's no way to forbid it as far as I know.
The following feature requests implicitly confirms this:
https://developercommunity.visualstudio.com/t/Users-able-to-change-required-reviewer-t/1196519
I have run into an issue where if my project managers are rushing, they sometimes will help move pull requests along by 'approving' them. As we have set the branch policy to require at least 2 approvals (and the creator cannot be one), this can be a bit of a frustration. I have moved the PMs into a new security group to isolate them from most options but I cannot find anything specific about Pull Requests. Does this just follow under the Contribute option or is there a specific way I can block them from being able to approve pull requests?
They have "Contribute to Pull Request" permissions, located under repo security settings. Remove that permission for the people you don't want to be approving PRs.