Review teams

Code reviewers are organized into review teams. Each team can set their own review conditions — for example, deciding to review PRs where certain files are modified, certain labels are applied, or a PR is being merged into a specific branch.

Conditions

Use conditions to determine when the team will be assigned to a pull request. Like other expressions, these can leverage the vast majority of the GitHub API for the pull request.

Reviewers

You can put any number of users into a review team. Note that, currently, PullApprove teams have no connection to GitHub teams.

Approval requirements

Each team can decide how many approvals are required, how many reviews are requested, and what happens if the author of a PR is also a reviewer.

Review requests

Docs coming soon

Contributor points

Docs coming soon

Reviewer instructions

When a team is assigned to a PR, the reviewer instructions are sent to the PR as a comment (@mentioning the pending reviewers).

Review instructions can be used to remind people how the process works, links to internal docs, or even provide a literal review checklist.

Labels

When labels are enabled for the organization, a "PA: {team} pending" label will be applied to the PR while the team is pending review. When the team is done reviewing, the label will be removed.

Team pull requests

On the "reviewers" page for your organization, you'll be able to see a list of the teams and the pull requests that they are currently reviewing:

FAQs

What about GitHub team review requests?

The PullApprove GitHub integration will only create review requests for individual users. It will never send a review request for an entire GitHub team.

While settings now exist to convert team requests into individual requests, we prefer to keep the GitHub integration simple and focused on individual users.

Workflow step condition or team condition?

Steps and teams can both have conditions, and they can be used for similar things. When used together (ex. your "In review" step), you might find yourself wondering where to put a condition.

Phase conditions should be used if the same rule applies to all teams, without exception. An example of this might be to only require review if the PR is being merged into the repo's default branch:

If the rule can't be applied to all teams, or if you want to apply different rules to different teams, then you should use a team condition instead.

The most common example of this is to assign a team to PRs based on the files that are modified:

In short, if a rule can obviously be applied to all pull requests for all teams, then use a phase condition. And if not, then use a team condition.