Overview
PullApprove is an alternative to CODEOWNERS, combining code ownership with approval requirements. It's designed to work for individual teams or entire organizations, across multiple repos or inside large monorepos.
For many large companies, code review is a strict requirement for compliance or regulatory purposes. PullApprove is designed to enforce these requirements in a highly customizable and scalable way, without becoming a burden on developers.
For the developer:
- Low-friction - For the authors and reviewers, the day-to-day experience does not drastically change from what they're used to. They still discuss, review, and approve PRs using the official GitHub/GitLab/Bitbucket products.
- Automatic - As soon as a PR is opened, the appropriate reviewers are automatically requested and everyone is reminded of the process to get the PR merged.
- Clear - Designed to bring clarity at every step of the way — from the
CODEREVIEW.toml
layout to the PR comments and statuses.
For the organization:
- Customizable - A more configurable review assignment and approval requirement system than GitHub/GitLab/Bitbucket provide.
- Scalable - Designed to scale across hundreds of repos, inside of large monorepos, and for high volumes of activity.
- Auditable - The entire configuration is stored in the repo, so it can be easily audited using existing git tooling.
CODEREVIEW.toml
PullApprove is configured directly in each repo with a CODEREVIEW.toml
file. This file defines review scopes
, which are path-based rules for who needs to review a change.
A simple example:
# CODEREVIEW.toml
[[scopes]]
name = "admins"
paths = ["**/*"]
reviewers = ["admin1", "admin2"]
request = 1
require = 1
[[scopes]]
name = "app"
paths = ["app/**/*"]
reviewers = ["dev1", "dev2", "dev3", "dev4"]
request = 2
require = 1
When a change is evaluated, files are matched to scopes based on their paths.
$ git diff --name-only
README.md
app/package.json
$ git review diff
README.md -> global
app/package.json -> app
Once this change is opened as a pull request, the scopes are used to request
(or not request) reviewers and require
(or not require) their approvals. When all scopes are satisfied, the PR gets a "success" status.
Scopes (basic)
name
- the unique name of the scopedescription
- a human-readable description of the scopereviewers
- who can approve changes in this scoperequest
- how many reviewers to requestrequire
- how many approvals are neededpaths
- which files are in this scope
Scopes (advanced)
instructions
- additional instructions for reviewersownership
- how scopes are combinedreviewed-for
- require explicit scope review (GitHub only)alternates
- additionally allowed reviewers that aren't requestedlabels
- label syncing for scopescode
- which lines of code match this scopeauthors
- which PR sauthors match this scopeauthor-value
- implicit approval by the PR author
Other root settings
aliases
- groups of reviewers that can be used in scopestemplate
- mark a file as a templatebranches
- when PullApprove runs
Comparison of code review tooling
Feature | v5 | v3 | v4 (GUI) | GitHub CODEOWNERS |
GitLab CODEOWNERS |
Bitbucket CODEOWNERS |
Kubernetes OWNERS |
---|---|---|---|---|---|---|---|
Config-as-code | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ | ✅ |
Path-based assignment | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Line-based assignment | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Label-based assignment | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Branch-based assignment | ? | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Expression-based assignment | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Implicit author approvals | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Implicit co-author approvals | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Per-team/scope approval requirements | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
Request N reviewers | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ |
PR labeling | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ✅ |
Eligible, unrequested reviewers | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Config sharing | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Multiple config files | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
Ownership hierarchy | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Ownership coverage | ? | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Review instructions | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Unavailable reviewers | ? | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ |
Hotfix/bypass | ? | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Post-merge reviews | ? | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ |
Phased reviews | ? | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Review nudge/reminder | ? | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ |
Suggested owner changes | ? | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |