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.

CODEOWNERS 101

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:

*.js    @js-owner

Then, every pull request that modifies a JavaScript file will trigger a review request to the js-owner team.

This can work for any file path, extension, etc.

Limitations

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.

Release management

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!