Skip to main content

Understanding Status Checks vs Code Review PR Reviews

Understanding the Relationship Between Legacy Code Filter and Protect What's New

David Martin avatar
Written by David Martin
Updated this week

When first starting with Code Reviews it's important to understand the differences between Status checks and PR reviews. This document aims to clarifies the distinction between Git Status Checks and targeted Code Reviews PR Reviews, explaining the role of the Legacy Code Filter in managing technical debt and ensuring a consistent development workflow.

Code Reviews PR scans

The feedback from Clayton[bots] takes a targeted approach. It analyzes only the files that have been changed in the current PR, highlighting issues specifically introduced by those changes while ignoring pre-existing problems. This method keeps feedback relevant to what was actually modified, avoiding legacy issues.


Status Checks

Unlike basic code reviews that only assess the new changes introduced in the PR, status checks analyze all files involved in the specific revision, regardless of whether the changes were made in the current or previous PRs.

This method ensures that the entire codebase remains healthy rather than just focusing on the changes being introduced. Even if a PR modifies just a few lines, the status check will flag any pre-existing issues within the affected commit, treating the entire commit as a single unit. Therefore, the report is considered "all-or-nothing" because any issues, newly introduced or inherited will result in a failed status check.

Legacy Code Filter


This filter excludes legacy code from the analysis based on a specified reference date. Consider this, you open a PR that modifies just three files, Code Reviews scans them and finds no new issues. Yet, the build status still fails. This happens because the status check examines the entire project, including untouched files that might contain legacy issues.

If you've enabled the Legacy Code Filter, Code Reviews's targeted review will correctly exclude those older problems. For example, if you set the reference date to "yesterday," only issues that have existed in the entire project since yesterday would be flagged in the status section. This allows your build to pass without being held up by pre-existing issues. Crucially, any items within your PR itself would remain unaffected by the reference date, no matter what it's set to. For more information on how to set up the Legacy code filter check out this guide.


Did this answer your question?