Log in to v4
Note that the docs are slightly behind the latest version of PullApprove v4.
Concepts are largely the same, but the UI is evolving daily.

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.

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.

Phase condition or team condition?

Phases and teams can both have conditions, and they can be used for similar things. When phases and teams are used together (ex. your "In review" phase), 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.