Whether they have ownership over specific files, areas of expertise, or
phases in the review process, you can use conditions to
loosely or precisely decide who needs to review which pull requests.
version: 3
groups:
database:
conditions:
- "'*migrations*' in files or 'database' in labels"
reviewers:
users:
- jeff
Not every pull request should be reviewed right away. And some PRs never need to be reviewed. You decide when reviewers need to get involved, and we'll make it happen.
version: 3
pullapprove_conditions:
- "'WIP' not in title"
- "'hotfix' not in labels"
- "base.ref == base.repo.default_branch"
- "'license/cla' in statuses.succeeded"
- "'*travis*' in statuses.succeeded"
groups:
...
PullApprove only requests a review when it is needed. You decide how many reviewers need to be requested at a time, and we'll cycle through them until enough approvals have been given.
version: 3
groups:
code:
reviews:
required: 4
request: 2
request_order: random
reviewers:
teams:
- code-review
Use notifications
to make it clear what needs to happen next in your process and what the expectations are
for the PR author and the reviewers.
version: 3
notifications:
- when: pull_request.opened
comment: |
Hey @{{ author }}, thanks for the PR!
The review will start once the tests and CI checks have passed.
You'll also need to sign our CLA if you haven't before.
groups:
...
Set your status to "unavailable" and we'll automatically remove your pending review requests, and prevent any new requests while you're away. Do yourself and your team a favor by not holding things up.
Easily share your code review workflows across your team and organization.
version: 3
extends: https://api.github.com/repos/example/pullapprove-config/contents/.pullapprove.yml