GitHub code review assignment with PullApprove

GitHub provides some great, basic features around code review assignment and requirements. But if your team needs more options, you don't have to build it yourself.

PullApprove was designed to give you all the flexibility of a custom tool, without the need to build or maintain one. You design your ideal code review process, and we'll do everything else.

Here's an example

Let's say our team wants to do four kinds of code review:

• Frontend - anything touching the interface should be reviewed by our "designers who code"
• Interns - John manages our interns directly, so we ask him to look over every PR they open
• Security - we have a security specialist to pull in as-needed
• General - each PR needs to be approved by two people, doesn't matter who

In PullApprove, we would codify these rules into a .pullapprove.yml, which is kept at the top of the repo.

For each type of review, we'll define a new group:

version: 3

groups:
  frontend: ...
  interns: ...
  security: ...
  general: ...

Frontend review

For the frontend group, we want them to review any JS change but we also have a label for when someone is concerned that the frontend might be affected. We can write this out as a "condition":

  frontend:
    conditions:
    - "'*.js' in files or 'frontend-review' in labels"

The frontend is important, so we want two people to get a review request notification and approve each PR (not the entire team):

  frontend:
    conditions:
    - "'*.html' in files or 'frontend-review' in labels"
    reviewers:
      teams: [frontend]
    reviews:
      request: 2
      required: 2
      request_order: random

Interns review

The conditions syntax gives us access to any metadata about the PR, including who authored it. So we'll ask John to review anything the interns open:

  intern:
    conditions:
    - "author in ['internA', 'internB']"
    reviewers:
      users: [john]

Security review

In React, we have some specific red flags we can look for such as dangerouslySetInnerHTML. We'll require a security review if someone adds a line that includes "dangerouslySetInnerHTML" (line starts with a "+" in the git diff).

  security:
    conditions:
    - "contains_regex(files.patches, '(?m)^\+.*dangerouslySetInnerHTML.*')"
    reviewers:
      users: [josh, jeff]
    reviews:
      request: 1
      required: 1

General code review

Finally, we want to make sure that every PR is approved by at least two people.

We'll put the entire company into this group, which means approvals could overlap from the other groups. In some cases we will already have enough approvals from the other groups, but if not then this will ensure someone else is requested.

  general:
    reviewers:
      teams:
      - developers
      - designers
      - admins
    reviews:
      request: 2
      required: 2

Putting it all together

When we're finished, we have a .pullapprove.yml that looks like this:

version: 3

groups:
  frontend:
    conditions:
    - "'*.html' in files or 'frontend-review' in labels"
    reviewers:
      teams: [frontend]
    reviews:
      request: 2
      required: 2
      request_order: random

  intern:
    conditions:
    - "author in ["internA", "internB"]"
    reviewers:
      users: [john]

  security:
    conditions:
    - "contains_regex(files.patches, '(?m)^\+.*dangerouslySetInnerHTML.*')"
    reviewers:
      users: [josh, jeff]
    reviews:
      request: 1
      required: 1

  general:
    reviewers:
      teams:
      - developers
      - designers
      - admins
    reviews:
      request: 2
      required: 2

Now we just need to commit this to the repo and install PullApprove! Review requests will be sent out automatically, and you can set "pullapprove" to be a required status check on the repo. Check out the docs to learn about the other advanced features not shown here.