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:

Check	Description
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-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: 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 head and base branches
• 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

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

Parameter	Type	Description
max-idle-days	number	Maximum 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

Parameter	Type	Description
max-lines	number	Maximum 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

Parameter	Type	Description
max-days	number	Maximum 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

Parameter	Type	Description
max-hours	number	Maximum 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

Parameter	Type	Description
max-comments	number	Maximum 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

Parameter	Type	Description
max-iterations	number	Maximum 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

Parameter	Type	Description
max-instability-rate	number	Maximum rate of build failure on pushes
min-commits	number	Minium number of commits before checking the instability rate
check-names	[]string	The 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

Parameter	Type	Description
max-rate	number	Maximum code churn rate between commits
min-deleted-lines	number	Minimum 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

Parameter	Type	Description
max-rate	number	Maximum code churn rate
max-days-period	number	The time period to take into account for the code churn computation. Any lines of code older than this time period is ignored.
min-deleted-lines	number	Minimum 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