Different Code Coverage from jacoco and sonarqube


(Edmund) #1


I’ve created a Java Project and deployed on jenkins, and used jacoco and sonarqube to check on the code coverage. However, I find out the code coverage calculation from jacoco and the one displayed in sonarqube is different. Where the sonarqube result is incorrect.

I’ve searched through Google to find the set up, but it is still generate the same result.

All related screen capture, including jenkins post step config:

From the above screen capture, I found out that the jacoco html report is the correct one as it showed the coverage of all files. But the sonarqube result only show the coverage on the test case file.

Jenkins: ver. 2.121.3
sonarqube: Version 7.1 (build 11001)

Could anyone can give some advice on solving this problem?

(G Ann Campbell) #2


Since several of your configurations use target paths, I’m assuming you’re building with Maven. You should then analyze with Maven as well. The benefit is that it handles most of this configuration for you and -by default- passes all the right locations.

In fact, your problem seems to be caused by misconfiguration. For instance, you’ve used both sonar.binaries (long-since deprecated) and synonym/replacement sonar.java.binaries, and you’ve pointed them to different places.


(Edmund) #3

Hi Ann

Thanks for your reply, this project is indeed a Maven project. And my settings of the project is same as the analyze with Maven , but the result is still the same.

Also I deleted the sonar.binaries in the config, but the result does not change as well. Besides, when I used the same config to execute the deprecated Post-build Action for Maven analysis, the coverage result will match the jacoco one. I’m not sure why it worked like this, do you have any other idea on what is wrong?


Thanks Ann for pointing out the misconfiguration issue, I finally found the sonar.java.binaries should set to just HelloWorld/target/, now the coverage calculation works like charm! The result is just the same as the deprecated Post-build Action for Maven analysis result. Many thanks!

(Nicolas Bontoux) #4

I would suggest taking a step back and checking how the SonarQube Scan behaves in Jenkins:

  • making sure that the latest generated JaCoCo report is well fed to the analyzer
  • enabling debug logs sonar.verbose=true to check how coverage import behaves
  • correlating that latest analysis with the latest JaCoCo report you get

Putting the comparison aside, the idea is to first understand how SonarQube numbers are obtained (knowing that SonarQube imports coverage data).