Appearance
Repository settings
Settings that affect a review are per repository, and there is no config file in your repository. Everything on this page lives on the settings page of a repository in the dashboard.
An organization can set the value new repositories start with, but not override a repository afterwards — see Organization settings.
Who can change them
Only an admin of the installation. That is the person who installed the GitHub App on that account, plus anyone an admin has since promoted. Everyone else sees the page with a View only badge and disabled controls. See roles.
Active settings
| Setting | Default | Effect |
|---|---|---|
| Enable AI review on Pull Requests | on | When off, no review is created for this repository and nothing is posted to your pull requests. |
| Trigger on PR events | opened · synchronize | Which pull request events start a review. reopened is offered but off by default. |
| Skip draft pull requests | on | While a pull request is a draft, no review is created. Marking it ready for review starts one. |
| Max files per review | 50 | How many files one review reads. The rest are skipped. |
| Exclude Patterns | a starter list | Globs whose matching files are skipped. The whole list is yours to edit. |
| Post review on GitHub | on | When off, the review runs but nothing of it reaches the pull request. |
| Comment severities | warning · critical | Only findings at the ticked levels are posted inline. |
| Post summary comment | on | Whether the review body appears at the top of the pull request. |
| Max comments per review | on, 20 | Caps how many findings are posted inline on one pull request. |
All of these are drafts until you press Save; Cancel discards them. Changes apply to the next review — one already running keeps the settings it started with.
Enable AI review
When off, EasyMerge creates no review for the repository at all. An event that arrives while it is off gets a check run of its own, completed as neutral and titled Review skipped.
Turning it back on applies to future pull request events only. A PR opened while reviews were off is not reviewed retroactively; push a commit to it to get one.
New repositories arrive with this on unless an admin has changed the organization default.
Trigger on PR events
Three checkboxes — opened, synchronize (a commit was pushed to the branch) and reopened. Only the events you tick start a review.
reopened is not ticked by default, so reopening a closed pull request does not produce a review unless you turn it on. Pushing a commit after reopening does, via synchronize.
One event ignores this setting: marking a draft pull request Ready for review always starts a review. So unticking all three does not silence EasyMerge completely — turn Enable AI review off if that is what you want.
Skip draft pull requests
While a pull request is marked draft, EasyMerge creates no review — opening it, and every push to it, is skipped. Marking it ready for review reviews the diff as it then stands.
Turn this off to have drafts reviewed like any other pull request.
Max files per review
How many files one review reads. Minimum 1.
Files excluded by a pattern, and files GitHub gives no diff for, are skipped before the cap applies and do not count against it. Of the files that remain, the first n are reviewed in the order GitHub lists them; the rest appear in the review detail as skipped, with the reason max_files_exceeded.
Raising it makes a wide pull request slower to review; lowering it means more of a wide pull request goes unread. See Large pull requests.
Exclude Patterns
A new repository starts with a list of patterns already filled in, covering lockfiles, build output, generated code and similar noise. That list is editable in full: remove any entry — including one that arrived with the repository — and files matching it are reviewed again.
The card states this directly: Files matching these patterns are skipped. Remove any entry, including a default, and the file is reviewed again. The matching rules sit under How matching works beside it.
Patterns are listed as chips, each with a ✕ to remove it. A chip carrying a coloured dot is one you added for this repository rather than one that arrived with it; a counter above the list reads 24 / 200, with 3 custom under it once you have added any of your own.
Add patterns one at a time with Add. Add defaults puts back any of the starting patterns you have removed, leaving the rest of your list alone; it is disabled, with the tooltip Every default pattern is already in the list, when nothing is missing.
Once the list passes a dozen patterns, a Filter patterns box appears above the chips, with a 12 of 44 count beside it while you type. It only narrows what is shown — filtering removes nothing — and the box clears when you add a pattern. When nothing matches, the card reads No patterns match "…".
Edit as text replaces the chips with a text box holding one pattern per line, for pasting a list or making several changes at once. Blank lines are ignored and repeats are collapsed. Apply (or ⌘↵) replaces the whole list with what you typed; Cancel (or Esc) discards it. A line that is not a valid pattern is reported by number — Line 7: Pattern is not a valid glob. — and nothing is applied until you fix it.
Validation:
| Rule | Message |
|---|---|
| Must not be empty | Pattern cannot be empty. |
| At most 255 characters | Pattern must be 255 characters or fewer. |
| Must be a valid glob | Pattern is not a valid glob. |
| No duplicates in the list | Pattern already exists. |
| At most 200 patterns | Exclude patterns are limited to 200. Remove some before adding more. |
AN EMPTY LIST REVIEWS EVERYTHING
Clear the list and the page reads No patterns. Every file will be reviewed — and it means it. There is no hidden set of exclusions underneath your list; lockfiles and build output are only skipped while the patterns that match them are in it. See Excluding files.
For pattern syntax, see Exclude pattern syntax.
Post review on GitHub
The master switch for everything EasyMerge puts on a pull request. It reads: Publish findings as inline comments, the summary and the check run on the pull request. When off, reviews still run in full and results stay in EasyMerge only. Applies to reviews created after saving.
With it off, a pull request gets no inline comments, no review body and no EasyMerge Review check run at all — not even a skipped one. The review itself still runs and its findings are readable in the dashboard, where the run is marked Not posted to GitHub, with Post review on GitHub was off for this run, so nothing of it reached the pull request. The findings below are only here.
Use it to try EasyMerge on a repository without anyone else seeing its comments.
Comment severities
Chips for info, warning and critical. Only findings at the levels you tick are posted inline; the rest are kept, and readable in the dashboard, but never reach the pull request.
info is not ticked by default, so minor maintainability findings do not appear on your pull requests unless you turn them on.
A finding held back this way is labelled not posted · severity filter in the review detail, and counted in the review body's footnote.
Post summary comment
Whether the review body — the recommendation callout, the finding counts and the confidence reading — is posted at the top of the pull request. Turn it off to get inline comments only.
The toggle is disabled while Post review on GitHub is off, and its description then reads Unavailable while Post review on GitHub is off.
Max comments per review
A number with a toggle beside it. While the toggle is on, a review posts at most that many inline comments; findings past the limit are kept and readable in the dashboard but not posted. The most serious findings are posted first, so what gets cut is the least important.
A finding held back this way is labelled not posted · comment limit in the review detail.
Turn the toggle off and every finding at the ticked severities is posted, however many there are. The description while the limit is on reads Caps noise on very large pull requests. Findings past the limit stay in EasyMerge.
Project status
One card on the page has nothing to do with reviews. Project status configures the light scan of the repository, and its View status link opens the result.
The card explains itself: Choose the single branch used by the manual light scan. Changing the branch clears the current result; no scan runs automatically.
Status branch
A single branch, chosen from the repository's branches on GitHub. It defaults to the GitHub default branch, and only that branch is ever scanned.
Changing it throws the current result away — the page goes back to Not scanned — and starts nothing in its place. Run a scan yourself afterwards.
The select is saved with everything else on the page, by Save. It is disabled for anyone who is not an admin, though running a scan needs no special role. If EasyMerge cannot reach GitHub for the branch list, the select offers only the branch already configured and the rest of the page still works.
Not yet active
One control on the settings page saves and persists, but has no effect on your reviews today:
| Control | Shown as | What actually happens |
|---|---|---|
| Default review profiles | none ticked | No label is put on a new pull request, and its review is unchanged |
The Label-based review profiles card lists three labels — deep-review, security and style-only — and lets you tick the ones every new pull request should start with, summarising the choice as New pull requests get: Deep review, Security focus — and New pull requests get: Standard review when none is ticked. Neither half works yet: no label is added when a pull request opens, and every pull request gets the same review whichever of these labels it carries. The card says as much under the list: Profiles are being rolled out; until they are enabled for your organization every review runs the standard profile.
Treat this section as the source of truth over the wording on the settings page until it ships.