Reviewpad Check is powerful tool to identify open Pull Requests that may require extra attention.
Reviewpad Check can provide crucial insights, such as Pull Requests with lots of review iterations, with high internal code churn or with lots of added lines. This information can help streamline the code review process by flagging potential issues for you.
Reviewpad Check is activated by default when enabling Reviewpad and automatically flag problematic open pull requests with some dedicated labels.
Reviewpad Check includes a variety of checks, most of which are activated by default even in the absence of a
However, you can refine their behavior using the
reviewpad.yml configuration file in the
Each check possesses a unique ID, adjustable parameters, and a default activation status.
non-conventional-commits, all the other checks are activated
by default when enabling Reviewpad. So the
activation property should be mainly used to deactivate
some checks which might not suit your needs:
Consider the example of the
stale check, designed to identify stale PRs:
stale: # 'stale' is the check id
parameters: # 'parameters' is the standard section introducing the adjustable parameters
max-idle-days: 30 # 'max-idle-days' is the only parameter of the 'stale' check
label: stale # `label` is the name to be used to flag stale PRs
activation: on # 'activation' status is either 'on' or 'off'
Most of the checks create the issues as soon as the problematic patterns appear.
As an example, the
large check triggers an issue as soon as the last commit
making the size of the pull request too large is pushed.
The only exception to this rule is for the
whose problematic patterns is based on a timeframe. For those three checks, Reviewpad Check evaluates
the open pull requests each hour.
Please note that each time Reviewpad Check runs, the Reviewpad's check status is set to
As soon as at least one issue is detected on an open pull request, a label is put on this pull request and a check report is created. This check report is a GitHub comment listing the identified issues with their descriptions.
Here is an example of a check report:
Reviewpad Check has identified the following issues:
|stale||Pull Request has been inactive for over 20 days.|
|many-review-iterations||Pull Request has undergone more than 5 review iterations.|
To tune or deactivate some checks, see the documentation.
Triggering Workflows on Issue Detection
Reviewpad allows you to trigger workflows in response to detected issues.
For example, if you want to automatically assign a
stale PR and post a comment on it, follow these steps:
- Create a dedicated workflow.
- Utilize the
trigger-on-checkproperty, setting it to the specific check ID, in this case,
Here's a sample configuration:
- name: handle-stale-pr
- $addComment("This Pull Request has been inactive for over 30 days @paul.")
It's important to understand that the
will be triggered only when a stale PR is detected.
List of Checks
Here is a description of all the available checks:
- stale: Pull Requests with no activity for too many days
- large: Pull Requests with lots of added lines
- long-lived: Pull Requests being open for too long
- long-pick-up-time: Pull Requests waiting for review for too long
- git-conflict: Pull Requests with a git conflict between the
- many-comments: Pull Requests with lots of review comments
- many-review-iterations: Pull Request with lots of review iterations
- non-conventional-commits: Pull Request with commit messages not complying with Conventional Commits specification
- unstable-build: Pull Request with high rate of pushes leading to a build failure
- high-internal-code-churn: Pull Request with high code churn between commits
- high-code-churn: Pull Request mainly rewriting some code introduced recently
stale spots pull requests with no activity for too many days. No activity means here
no commits and no comments.
Stale pull requests, those left unattended, can slow project progress and compromise code quality. As they age, they often grow out of sync with the evolving codebase, leading to difficult integrations and diminishing relevance. Unaddressed, they can also hint at bottlenecks or communication gaps in the review process. Therefore, it's crucial to monitor and address stale pull requests promptly to maintain smooth development workflow.
|number||Maximum number of days with no activity|
large spots pull requests with lots of added lines.
Large pull requests present a challenge in code reviews. Their sheer size can be overwhelming, making them more time-consuming to review and increasing the likelihood of overlooking errors. They often encompass multiple changes that can be difficult to understand in a single context, complicating the review process.
|number||Maximum number of added lines|
long-lived spots pull requests being open for too many days.
Long-lived pull requests can become a significant bottleneck in the development pipeline. They often imply that changes are not being integrated regularly, which can lead to complex merges and increased potential for conflicts as the codebase evolves. This can delay the delivery of features and bug fixes, thereby negatively impacting team productivity and software release schedules.
|number||Maximum number of days since the creation|
long-pick-up-time spots pull requests waiting to be reviewed for too long.
Extended wait times for pull request reviews can seriously hinder progress and stifle productivity. When authors have to wait excessively for reviews, it not only delays the incorporation of their changes into the main codebase, but also leaves them in a state of limbo, reducing their efficiency. Over time, this can lead to demotivation and a slow-down in development velocity.
|number||Maximum number of hours waiting for a review|
max-hours: 72 # 3 days by default
git-conflict spots pull requests with a git conflict between the
Identifying and resolving git conflicts swiftly in a pull request is crucial for several reasons. Conflicts can cause code inconsistencies, affect code integrity, and potentially introduce bugs if not properly managed. The longer these conflicts persist, the more complicated they can become to resolve, especially as other code changes are added. This can lead to delays in feature deployment and increased workload for developers.
many-comments spots pull requests with lots of review comments.
Spotting pull requests with a high number of review comments quickly is essential as it can be indicative of potential misalignments among stakeholders. A large number of comments can signal disagreements over code implementation, design decisions, or project direction, which can lead to extended deliberations and slow down the development process. It might also suggest that the pull request is complex or unclear, prompting numerous queries for clarification.
|number||Maximum number of comments|
many-review-iterations spots pull requests with lots of different code changes coming from reviews.
Identifying pull requests with numerous code changes resulting from reviews promptly is vital for effective project management. Excessive alterations due to reviews might suggest that the initial pull request was not adequately thought out or implemented, leading to a higher cost in time and effort during the review phase. Additionally, it could indicate a lack of clarity in project requirements or a disparity in coding standards or practices within the team.
|number||Maximum number of different code changes coming from reviews|
non-conventional-commits spots pull requests with some commit messages not complying with the Conventional Commits specification.
Adhering to the Conventional Commits specification in pull request commit messages can greatly enhance clarity, consistency, and overall project management. This specification involves structured commit messages that clearly define the purpose and impact of each commit, thereby facilitating an easy understanding of the changes made. This not only aids in code review by providing valuable context to reviewers, but it also supports automated tools in generating meaningful release notes, version bumps, or changelogs.
unstable-build spots pull requests with high rate of pushes leading to a build failure.
Monitoring the build failure rate on a pull request is crucial to maintain the overall quality and stability of the project. Frequent build failures could indicate that the proposed changes are either introducing bugs, breaking existing functionality, or not aligning well with the current codebase. This could lead to a substantial amount of wasted time and resources in continuous debugging and fixing. Additionally, a high instability rate may demoralize the author of the pull request, slowing down their productivity.
|number||Maximum rate of build failure on pushes|
|number||Minium number of commits before checking the instability rate|
|string||The GitHub check names to take into account. By default, all of them.|
max-instability-rate: 40 # percentage
high-internal-code-churn spots pull requests with high code churn between commits.
Keeping track of the code churn within a pull request—measured by the frequency of lines added, modified, or deleted between commits—is significant in maintaining efficient development practices. High code churn could indicate several issues: the feature or fix may not have been well defined from the start, leading to constant revisions; the author might be facing difficulties in implementing the changes; or the code might not be aligning with the existing codebase, necessitating frequent modifications. High churn rates often result in longer code review times, potential introduction of bugs, and delays in project timelines. Moreover, they may signal the need for additional support or guidance for the author.
|number||Maximum code churn rate between commits|
|number||Minimum total number of deleted lines accross all commits to trigger an issue.|
high-code-churn spots pull requests mainly rewriting some code introduced recently.
Tracking code churn—specifically when it involves recent changes in the codebase—is essential to maintaining code stability and developer efficiency. High churn rates where new modifications override recent updates might signal issues like frequent changes in project requirements, code instability, or lack of alignment between team members' work. This can lead to confusion, waste of effort, and increased likelihood of introducing bugs. Moreover, it may suggest the need for better communication, more thorough planning, or clearer coding guidelines.
|number||Maximum code churn rate|
|number||The time period to take into account for the code churn computation. Any lines of code older than this time period is ignored.|
|number||Minimum number of deleted lines to trigger an issue.|