GitHub CODEOWNERS on steroids
For the last few years, GitHub has supported a feature named CODEOWNERS. If you never heard of it, it’s a file that you can put in your repository, and that will make GitHub assigned pull request reviews to users or teams.
Ok, so if you’re really new to this file, let me give you a simple example. Let’s say that your .github/CODEOWNERS file in your repository has this:
This can work for any file path, extension, etc.
While this mechanism is very handy, it’s also really limited. This can only match based on file names, paths or extensions, but not on any other criteria of the pull request. There a lot of different scenarios that are interesting; let’s see how you can leverage Mergify to implement them.
Team-based review request
It’s pretty common to have developers organized in several teams. They usually work on common features so they are well aware of what each other is doing.
It sounds pretty obvious that anyone from a particular team should have their code reviewed by a member of the same team.
pull_request_rules: - name: assign PR from @myteam to @myteam conditions: - author=@myteam - -merged actions: request_reviews: teams: - myteam
For each pull request that is authored by a member of @myteam and that is not yet merged, a request_review will be added for @myteam.
Requesting reviews with labels
It’s pretty common to use labels to categorize your pull request. You could have a label for UI changes, one for backend changes, etc. Those pull request could be assigned to different teams.
Let’s say we have a label ui in our repository that is used to identify user-interface changes. Those changes should be reviewed by the @react-ui team.
pull_request_rules: - name: request review from React devs conditions: - label=ui - label!=work-in-progress - -merged - files~=/.*\.jsx$ actions: request_reviews: teams: - @react-ui
We’ve put a few more conditions in this rule. First, the pull request should be opened and have the label ui set. We also want to be sure the JSX files are modified. Finally, if the pull request has the label work-in-progress there’s no need to request a review yet, so we don’t do it.
If you use dedicated branches for release for your software, having your release manager reviewing for stable branches might be interesting. You could write a rule like:
pull_request_rules - name: ask RM to review the PR conditions: - base~=stable/.* actions: request_reviews: users: - your-release-manager-login
With such a rule, a review will be requested each time a pull request is opened against a branch under the stable/ namespace.
There are plenty more workflows that you could implement with Mergify. We’ve added a few in our documentation examples section. Feel free to suggest more ideas!