Tuning reviews
In-repo config
Add an .inline.yml file to a repository and inline reads it on every review. Your review rules then live where the code lives, and change the way the code changes.
Anyone who can open a pull request can add or change this file. That is the point of it: a change to your review rules gets reviewed like any other change.
#Where to put it
inline looks for .inline.yml at the root of the repository. It also accepts .inline.yaml, or .github/inline.yml if your repository config already lives in .github.
On a pull request, inline reads the file as it stands on that pull request's own head. Change a rule and open a pull request, and the review of that pull request already follows the new rule, so you can see what it does before it lands.
#What goes in it
A small file covers most of what teams want:
version: 1
review:
severity_threshold: high
instructions: |
This service handles patient data. Treat any handling of it as high severity.
ignore:
- "**/*.generated.ts"
- "docs/**"
path_instructions:
- path: "src/billing/**"
instructions: Money is in cents everywhere. Flag any float arithmetic.
features:
walkthrough: true
sandbox_tests: true
learnings:
- Flag any HMAC comparison that is not constant-time.
| Key | What it sets |
|---|---|
| version | Required. The file format version. |
| review.severity_threshold | How serious a finding has to be before inline posts it. |
| review.instructions | Standing context for every review of this repository. |
| review.ignore | Globs to skip, on top of the ones inline always skips. |
| path_instructions | Instructions that apply to one part of the tree, so a directory can carry rules of its own. |
| features | Switches for walkthrough, sandbox_tests, breaking_change_checks, fix and lint. |
| learnings | House rules, the same kind you can teach with @inline learn. |
#How it combines with the portal
The file is the most specific place a rule can live, so for most settings it wins over both the repository's own settings and the workspace defaults.
Three behave differently, and each difference is there to stop a repository quietly loosening something your workspace decided.
| Key | How it combines |
|---|---|
| features | Can switch a feature off for this repository, and cannot switch on something the workspace has off. |
| severity_threshold | Can only tighten. A repository can ask for more than the workspace requires, not less. |
| review.ignore, review.instructions, learnings | Added to the portal values rather than replacing them. |
#Checking inline read it
The in-repo config card on the repository's settings shows whether inline found a file and which commit it read. See Repository settings.
Where something in the file went past a limit, inline says so on the pull request's walkthrough comment rather than failing silently. The limits are generous: 64 KB for the file, 50 path instructions of up to 2,000 characters each, and 50 learnings.
In-repo config is included with Pro. See Plans and billing.