Is there a way to disable email notifications to the default owners configured in a github CODEOWNERS file?
In the code owners documentation, I can only find the following:
These owners will be the default owners for everything in
the repo. Unless a later match takes precedence,
#global-owner1 and #global-owner2 will be requested for
review when someone opens a pull request.
#global-owner1 #global-owner2
While I do want to have the default code owners, I don't want an email notification being sent out to each code owner for each push, review remark, review approval, merge, etc. It's to much spam and makes it easy to overlook important notifications, e.g., when someone is explicitly added as a reviewer or mentioned in a comment.
The CODEOWNERS notification system can not be turned off. But you can turn off all notification from a repository from the repository settings.
Related
I'm been working in a team of four. I'm in the collaborator list. I'm able to commit, push, send pull requests and merge in our repo. My teammates can see my changes, but everyone is on the contributor list except me.
I double checked my email address, make sure the email I used in my local setting is the same with my default email in the github account.
We have changed the owner of the project once, and I'm still using the old url. Is this the reason for that?
I found the github has a complex rule for you be considered as a contributor. Here's the doc of it.
https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/why-are-my-contributions-not-showing-up-on-my-profile
You have to commit to the main/default branch or make pull requests. To commit into other branches won't count.
Also, to use the old project url is definately one problem. In the project insight, everyone's profile is linked with their username. While mine is only a username with no user icon.
I think I just accidentally hit into one of the corner cases, but I'm still very confused of this design pattern.
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”.
Sorry, this is not really a development question but I don't know where to ask (SuperUser?)
I'm using my GitHub account for private and professional repositories and I'm getting about 40 email notifications a day for one repository I'm not interested in.
I tried to deactivate notifications for this repository but only found a way to deactivate notifications for new repositories.
Apart from setting up an email filter - what am I missing here?
Based on Github's site
You can configure notifications for a repository on the repository
page, or on your watching page.
and
You can customize notifications for a repository, for example, you can
choose to only be notified when updates to one or more types of events
(issues, pull request, releases, discussions) happen within a
repository, or ignore all notifications for a repository. For more
information, see "Viewing your subscriptions."
And from what I have seen: This is where you find it Enter the repo, Settings, notifications, and you have the 'Active' checkbox.
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.
I do pull requests in a repo where it's always the same person reviewing.
I would like to set him as the default reviewer so that I don't always have to choose him at each pull request, it'd be automatic.
How to do that ?
GitHub has the ability to set the default reviewer using a CODEOWNERS file.
Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. When someone with admin permissions has enabled required reviews, they can optionally require approval from a code owner.
To use a CODEOWNERS file, create a new file called CODEOWNERS in the root, docs/, or .github/ directory of the repository, in the branch where you'd like to add the code owners.
You should add .github/CODEOWNERS file with users to send PR to.
Example to send PR for any change on codebase represented by *:
## code changes will send PR to following users
* #option1-user1 #option1-user2 #option2-your-org/team-name
See: https://docs.github.com/en/enterprise/2.18/user/github/creating-cloning-and-archiving-repositories/about-code-owners
Note: .github/CODEOWNERS should be in main branch to be effective.