Invalid new code detection on rebased features branches

SonarQube Server / Community Build
1

Version: Sonarqube 8.2 with latest plugins

We work extensively with features branches to have the quality gate blocking gitlab merge requests.

Many time we faces issue with rebased features branches. Turns out rebasing a branch makes the intermediate commits from the target branch being included in the analysis, which causes all sorts of problems. In a branch, I’ve 2 changed lines and the new code show me around 400 lines. This cause the quality gate to fail as the code coverage is less than the threshold.

As someone already seen this kind of error ? Or perhaps, we do a bad usage ?

2

Hi Raphael

I am not sur to understand your full setup but you can analyses the base branch first. See the documentation:
https://docs.sonarqube.org/latest/branches/overview/

Than for PR you can provide base branch see documentation:
https://docs.sonarqube.org/latest/analysis/pull-request/

You need to provide the correct parameter for the setting:
sonar.pullrequest.base

Now it depend on you ALM you are using. If you need more help on ALM setting please let us know where you struggle.

3

I am experiencing similar issues. We have a big repository that generates multiple PRs daily. If a developer created a PR several days ago, then pushes his commits to it - if in the meantime master branch was pushed forward by other PRs - then the said developer sees code from other PRs (ones that were already merged to the master branch) as new code on his PR (so let’s say he changed a few lines in flie A - and that’s all, Sonar reports issues in files B, C, etc… - all untouched in the said PR)

Adding sonar.pullrequest.* settings (ones described in https://docs.sonarqube.org/latest/analysis/pull-request/ ) in our gitlab Ci job running the scan doesn’t change anything in this regard.

It’s as if Sonar was comparing contents of the PR against the latest version of the master branch, without limiting itself only to changes introduced by the PR.