When first starting with Code Reviews, it's important to understand the differences between branch scans and PR scans. This document aims to clarify the distinction between Code Reviews Status Checks (branch scans) 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
PR scans take a targeted approach. Code Reviews looks only at the files changed in the current PR and flags issues introduced by those specific changes. Pre-existing problems elsewhere in the codebase are ignored entirely.
Where you'll see PR scan results:
As comments posted directly on the PR in your VCS (GitHub, GitLab, Bitbucket, Azure DevOps) either inline on the specific line, or as a summary comment or threads, depending on the rule and provider.
In the Automated Code Reviews tab of the relevant environment in your Gearset Pipeline, which lists issues grouped by severity (Critical / Error / Warning). You can click on
View reportto look into the issues.
Code Reviews Status Checks
Status checks from Code Reviews are showing the results of the revision scan which is on the head (last commit) of the source branch (feature branch) of the PR.
Each policy for your project maps to an individual status check on your PR (Intentional, Automated, Engaging, Resilient, Secure, Reliable, Compliant).
Unlike a PR scan, a status check evaluates every file in the full revision, regardless of whether it was touched by this PR. This means:
A PR that only changes three lines can still fail its status check if there are pre-existing issues anywhere else in that revision.
The result is effectively all-or-nothing: any violation found on the feature branch, new or inherited, fails the check.
This is by design: status checks exist to protect the overall health of the codebase, not just the differences.
Where you'll see status check results:
As a named check in your VCS's PR checks list (e.g. GitHub's "checks" panel), showing pass/fail per policy.
Reflected in the Gearset Pipeline environment when clicking on the PR under
Reviewers and other checks.
Please note that if a branch protection rule requires the Code Reviews status checks and/or PR reviews to pass, it will block merging in your VCS until it passes. Gearset does not block merging on its own; the block happens in the VCS based on the rules you've configured there.
Legacy Code Filter and Reference Date
Because status checks scan the entire revision, customers are often surprised when a small PR fails a check due to issues it didn't introduce. This is where the Legacy Code Filter and reference date come in.
The legacy code reference date excludes older issues from the status check results.
For example, setting the reference date to "yesterday" means only issues that have existed in the project since yesterday will be flagged in the status checks. Anything older is treated as legacy and ignored.
You configure this when setting up the protection mode:
The Legacy Code filter controls which results are shown in the UI.
When the toggle is off, results before the reference date are hidden from view.
Turning the toggle on shows everything again. The reference date itself doesn't disappear, it's just not being applied in the UI to filter the results.
A few things worth mentioning are:
The legacy code filter can be used to filter out the legacy code for branch scans and the status check results. It has no effect on PR scan results, because PR scans already only look at the current difference.
Issues introduced within the PR itself are never filtered out, no matter what the reference date is set to. The filter only protects against pre-existing problems elsewhere in the revision.
If the filter is on, the status check evaluates the full revision with no date cutoff, which is when the "3-line PR fails the build" scenario is most likely to occur.