Pull Request Analysis ignores new issues in changed source file outside the changed lines of code

we have been using the PR-Analysis feature of SonarQube for a couple of months now. We set up a SonarQube Quality Gate on the PR in order to protect the main branch. Despite this, we are occasionally observing Sonar issues popping up on the main branch. Those issues should have been found on the PR and “closed” the Quality Gate.


The details:

  • versions used: SonarQube Developer Edition 7.9.1, Gradle Plugin id ‘org.sonarqube’ version ‘2.8’, Jdk 11, BitBucket 6.7.2
  • error observed: Pull Request Analysis shows only issues located in changed lines of code, but not issues indirectly caused by the change
  • steps to reproduce:
    • On the develop-Branch (the master branch), create a Class with one private member variable and a setter-Mehtod.
    • On a PR-Branch, remove the setter-Methode, commit, push
    • The PR-Analysis does not report an issue for the unused variable (This is the problem!)
    • After the merge of the PR to develop, this causes a Sonar-Issue (squid:S1068) because of the unused variable.
  • potential workaround: do an incremental analysis in the IDE with SonarLint, or do a full analyis of the PR-Branch in the CI-Build.


In SonarQube 7.9.1, that’s not the expected behavior. When analyzing a PR target ‘master’, there is two strategies depending whether the target (‘master’ in this case) exists in SonarQube:

  1. If it exists: issues in the PR are compared with the issues in the target. The issue is shown only if the issue doesn’t already exist in the target.
  2. If it doesn’t exist: issues in the PR are only shown if one of its locations involves a changed code.

Looks like strategy 1. should be used in your example.
Your steps to reproduce didn’t work for me. A class with a private member and a setter already triggers S1068 (since the variable is only set and never accessed).

In any case, for v8.1 we plan to always use strategy 2., so this will happen occasionally. The reason for this change is that code in SQ is not always in sync with code in the SCM, so we think it’s better for the PRs to only rely on information coming from the SCM, as it’s the case with the classification of lines of code as new or not new.

Thanks - the information about the 2 strategies in the previous post was helpful.
It seem that observed behaviour results from strategy 2.

I was able to solve the problem by renaming the master branch of the project to “develop” (which is the real name of the branch). See How to change the main branch in SonarQube? for instructions.

Now the analysis spots the indirectly caused issue. This would indicate that strategy 1 was used.

BTW, I don’t think always using strategy 2 is a good idea. This would let through many issues. Therefore, it would not be a reliable Quality Gate.

Many thanks