Skip to main content
Version: v4

Reviewpad Check

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.

Configuration

Reviewpad Check includes a variety of checks, most of which are activated by default even in the absence of a reviewpad.yml file. However, you can refine their behavior using the reviewpad.yml configuration file in the checks: section. Each check possesses a unique ID, adjustable parameters, and a default activation status.

Apart from 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: activation: off.

Consider the example of the stale check, designed to identify stale PRs:

checks:
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'

Issue Detection

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 stale, long-pick-up-time and long-lived checks whose problematic patterns is based on a timeframe. For those three checks, Reviewpad Check evaluates the open pull requests each hour.

info

Please note that each time Reviewpad Check runs, the Reviewpad's check status is set to pending.

Check Report

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:

CheckDescription
stalePull Request has been inactive for over 20 days.
many-review-iterationsPull 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-check property, setting it to the specific check ID, in this case, stale.

Here's a sample configuration:

workflows:
- name: handle-stale-pr
trigger-on-check: stale
run:
- $addReviewers(["paul"])
- $addComment("This Pull Request has been inactive for over 30 days @paul.")
note

It's important to understand that the handle-stale-pr workflow will be triggered only when a stale PR is detected.

List of Checks

Here is a description of all the available checks:


stale

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.

Parameters

ParameterTypeDescription
max-idle-daysnumberMaximum number of days with no activity

Default Configuration

checks:
stale:
parameters:
max-idle-days: 15
label: stale
activation: on

large

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.

Parameters

ParameterTypeDescription
max-linesnumberMaximum number of added lines

Default Configuration

checks:
large:
parameters:
max-lines: 400
label: large
activation: on

long-lived

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.

Parameters

ParameterTypeDescription
max-daysnumberMaximum number of days since the creation

Default Configuration

checks:
long-lived:
parameters:
max-days: 30
label: long-lived
activation: on

long-pick-up-time

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.

Parameters

ParameterTypeDescription
max-hoursnumberMaximum number of hours waiting for a review

Default Configuration

checks:
long-pick-up-time:
parameters:
max-hours: 72 # 3 days by default
label: long-pick-up-time
activation: on

git-conflict

git-conflict spots pull requests with a git conflict between the head and base branches.

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.

Parameters

No parameter

Default Configuration

checks:
git-conflict:
label: git-conflict
activation: on

many-comments

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.

Parameters

ParameterTypeDescription
max-commentsnumberMaximum number of comments

Default Configuration

checks:
many-comments:
parameters:
max-comments: 20
label: many-comments
activation: on

many-review-iterations

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.

Parameters

ParameterTypeDescription
max-iterationsnumberMaximum number of different code changes coming from reviews

Default Configuration

checks:
many-review-iterations:
parameters:
max-iterations: 6
label: many-review-iterations
activation: on

non-conventional-commits

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.

Parameters

No parameter

Default Configuration

checks:
non-conventional-commits:
label: non-conventional-commits
activation: off

unstable-build

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.

Parameters

ParameterTypeDescription
max-instability-ratenumberMaximum rate of build failure on pushes
min-commitsnumberMinium number of commits before checking the instability rate
check-names[]stringThe GitHub check names to take into account. By default, all of them.

Default Configuration

checks:
unstable-build:
parameters:
max-instability-rate: 40 # percentage
min-commits: 5
check-names:
label: unstable-build
activation: on

high-internal-code-churn

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.

Parameters

ParameterTypeDescription
max-ratenumberMaximum code churn rate between commits
min-deleted-linesnumberMinimum total number of deleted lines accross all commits to trigger an issue.

Default Configuration

checks:
high-internal-code-churn:
parameters:
max-rate: 40
min-deleted-lines: 100
label: high-internal-code-churn
activation: on

high-code-churn

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.

Parameters

ParameterTypeDescription
max-ratenumberMaximum code churn rate
max-days-periodnumberThe time period to take into account for the code churn computation. Any lines of code older than this time period is ignored.
min-deleted-linesnumberMinimum number of deleted lines to trigger an issue.

Default Configuration

checks:
high-code-churn:
parameters:
max-rate: 40
past-days-period: 30
min-deleted-lines: 100
label: high-code-churn
activation: on