How much code is actually scanned during PR analysis?

SonarQube
,
1

SonarQube version: 8.9.1
SonarQube Gradle Plugin version: 2.8

Hi all,

We are doing PR analysis on our Java sources and have checks in place to ensure that issues are not allowed to be merged in. Recently, we’ve noticed a few issues sliding by. Some of these make sense (e.g., some FindBugs cross-file issues that Sonar Scanner isn’t able to detect since they occur in unmodified files), but others are simple ones in modified classes that we would have expected SonarQube to find during the PR. We’ve looked back at our original PR analyses in SonarQube and sure enough the problematic code is there but no issues were flagged.

The three examples we have right now are java:S1068, java:S1481, and java:S1854. All three are basically “unused variable” checks. The one thing in common is that in each case the variables are declared on lines that weren’t modified in the PRs (the PRs just removed all usages, but didn’t modify the variable declarations/definitions).

It seems like Sonar Scanner might not be adding violations for anything that isn’t on a modified line. Does anyone have any insight on PR analysis for modified vs. unmodified lines? Is it normal for these kinds of issues to get skipped, and are some rules different from others in terms of ignoring unmodified lines?

Thanks in advance!

2

Hey there.

Yes – in SonarQube v8.9 LTS, only issues that have an issue location on a changed line are raised in Pull Request Analysis. There is a feature request out there (FR-9: PRs should show all new issues, not just the ones on changed code) to hopefully someday address the shortcomings of this strategy (that issues like the ones you’ve mentioned, or file-level issues, are raised during PR analysis).