GitHub code review assignment with PullApprove
Tags: github, codereview, pullapprove, showdev
Published: 2021-03-12 23:04:43

---
title: GitHub code review assignment with PullApprove
published: true
description: An example of how PullApprove can be used to automated code review assignment for teams on GitHub.
tags: github, codereview, pullapprove, showdev
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ojah3lxgk4ibm6d1ajjv.png
---

GitHub provides some great, basic features around code review [assignment](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners) and [requirements](https://docs.github.com/en/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging). But if your team needs more options, you don't have to build it yourself.

**[PullApprove](https://www.pullapprove.com/) 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](https://docs.pullapprove.com/config/groups/):

```yaml
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"](https://docs.pullapprove.com/config/conditions/):

```yaml
  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):

```yaml
  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](https://docs.pullapprove.com/context/), including who authored it. So we'll ask John to review anything the interns open:

```yaml
  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`](https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml). We'll require a security review if someone adds a line that includes "dangerouslySetInnerHTML" (line starts with a "+" in the git diff).

```yaml
  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.

```yaml
  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:

```yaml
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](https://www.pullapprove.com/)! 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](https://docs.pullapprove.com/) to learn about the other advanced features not shown here.