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 scope
  • description - a human-readable description of the scope
  • reviewers - who can approve changes in this scope
  • request - how many reviewers to request
  • require - how many approvals are needed
  • paths - which files are in this scope

Scopes (advanced)

  • instructions - additional instructions for reviewers
  • ownership - how scopes are combined
  • reviewed-for - require explicit scope review (GitHub only)
  • alternates - additionally allowed reviewers that aren't requested
  • labels - label syncing for scopes
  • code - which lines of code match this scope
  • authors - which PR sauthors match this scope
  • author-value - implicit approval by the PR author

Other root settings

  • aliases - groups of reviewers that can be used in scopes
  • template - mark a file as a template
  • branches - 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 ?