Discrepancy in Expected Coverage After Merge on PR Analysis

SonarQube Server / Community Build
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    • Data Center Edition
    • Version 9.9.3
  • how is SonarQube deployed: zip, Docker, Helm
  • what are you trying to achieve
    • Get PR Analysis, that would report correct numbers for New Coverage and Expected Coverage After Merge
  • what have you tried so far to achieve this

On our PRs I have noticed huge discrepancy in the Project Code Coverage and Expected Coverage After Merge:

Project code coverage: 14.5%

New coverage: N/A

Expected coverage after merge: 28.8%.

IIUC, Expected Coverage after merge is supposed to give the total coverage after the PR being analyzed has been merged. We are using Scala and I run the command, ‘sbt clean coverage test coverageAggregate’, before running the Sonar scan in our Bitbucket pipeline.

I think Project code coverage, runs the test coverage and uses the properties in sonar-project.properties that rightfully considers the UI lines to be covered (along with some exclusions). Expected Coverage after merge on the other hand seems to be using only the results of the scoverage analysis (which comes out be ~28%), and does not really take the remaining lines in codebase (non-Scala/UI) into consideration.

Is my understanding correct? If not, what is causing this issue and how can I fix it?

2

Hi,

Welcome to the community!

That “expected coverage after merge” number is not - as you have discovered - something you should take to the bank. It’s an estimate.

PR analysis focuses only on the code that was changed in the PR. Was any non-Scala code changed in the PR?

On a side note, as a Data Center customer, you have access to our professional Support Engineers, who have things like SLAs. :smiley:

 
Ann