Review Pull Requests
When reviews run, which commits get reviewed, and how to review on demand.
When reviews run#
Solemly reviews a pull request when it's:
- GitHub: opened, marked ready for review, updated with new commits, or reopened
- GitLab: opened, reopened or updated
- Bitbucket: created or updated
Draft pull requests are skipped on all three hosts until they're marked ready. Closed pull requests aren't reviewed.
Review when#
Each repository chooses when automatic reviews happen, in Repository Settings:
| Setting | Behaviour |
|---|---|
| Every push (default) | Reviews every new commit. |
| Once per PR | Reviews a pull request once. Later pushes are skipped unless you ask. A review that failed or was superseded doesn't count. |
| On request | Never reviews automatically. Comment @solemly review when you want one. |
A commit that's skipped still gets a status, so the pull request isn't left waiting: a neutral Review skipped check on GitHub, and a successful status on GitLab and Bitbucket. A skipped review never blocks a merge.
Per pull request#
A pull request can override its repository's setting with PR commands:
@solemly review alwaysreviews every new commit on this pull request.@solemly pausestops automatic reviews on this pull request.@solemly resumegoes back to the repository's setting.
Grouped pushes#
The first review of a pull request starts right away. When you push several commits in quick succession, Solemly waits briefly and reviews the latest one, so a burst of pushes gets one review.
Latest commit only#
When you push a new commit, any review of an older commit that's still waiting or running is superseded: its check reports Superseded, and its result is never posted. You only ever see reviews of the latest code.
Review on demand#
- From the pull request: comment
@solemly reviewto review the latest commit, or@solemly review fullto review it again even if it was already reviewed. - From the dashboard: on Reviews, workspace admins can click Review now on a skipped review, or Retry on one that failed.
Large pull requests#
Very large changes are reviewed with less surrounding context, and the review footer says context truncated. A change too large to review at all gets a Pull request too large check that doesn't block the merge, so splitting it up helps. Some files are always left out, such as lockfiles and generated code. See Controlling Noise.
What counts toward your plan#
Reviews are counted per pull request, per month: the first review of a pull request in a usage month counts once, and later pushes to it that month are free. Skipped, failed and superseded reviews don't count. See Plans & Usage.
Something missing or unclear? Tell us.