SonarCloud scanner not showing coverage metrics for some Java projects

java
sonarcloud
coverage

(Roy Sela) #1

Hi, I have several java projects (but not all) which stopped showing the code coverage metric sometime during the past 3 weeks, even without any code change… For example, I chose a repository with little changes over the past month, which previously had shown coverage but not anymore.

I’ve checkout and re-ran tests for last month’s commit which was already sent to SonarCloud:

Back then it had coverage:

I have verified the build is ok and tests were actually run:

I’ve also verified that a fresh jacoco report is created

I ran the (freshly downloaded) scanner and did not notice anything wrong:
sonar-scanner -Dsonar.login=XXX -Dsonar.host.url=https://sonarcloud.io -Dsonar.organization=XXX -Dsonar.projectKey=XXX -Dsonar.sources=./app -Dsonar.java.binaries=./target/scala-2.12/classes,./target/web/classes -Dsonar.jacoco.reportPaths=jacoco-merged/merged.exec -Dsonar.branch.name=FEB-11

The scanner output seems ok:

But nothing shows in the freshly created branch in SonarCloud:

Although the background task finished successfully:

Context looks fine (and without any changes over the past 6 months…):

So, same code (and same test results) - but no coverage despite the fact it used to report it. I see similar issues in 3 other java projects as well (although there are other ones that report fine the coverage metric), can anyone please take a closer look?


(Michael Gumowski) #3

Hello Roy,

This is indeed quite unexpected. The last release of SonarJava is precisely from around 3 weeks ago ( Feb 19, 2019). Looking at the backlog however, the only thing which seems related to me is this ticket:
SONARJAVA-2912: Upgrade ASM to 7 and JaCoCo to 0.8.3.

I’m surprised that this change would have such side effect, especially looking at the logs, where everything is normal.

From my point of view, there is 2 things you may try:

  • Try using JaCoCo 0.8.3 to generate the exec report
  • Try changing the format of the report to XML (which is most probably soon going to be the default one, but we didn’t announced it yet). It’s another sensor which read this format.

Hope this helps,
Michael


(Roy Sela) #4

Hi Michael,

Yes, we first saw this issue on Feb 20, so it makes perfect sense.

Unfortunately our Java projects are based on Java Play using SBT, so we use the sbt-jacoco plugin and not jacoco itself, and while jacoco 0.8.3 was released on Jan 24, sbt-jacoco itself was last released on Jun 22 2018 and is set to use jacoco 0.7.9 - so that approach is blocked for us.

Regarding the XML format, when I changed the jacoco output format to xml, i got the following exception:

I used the following command (just changed the jacoco.reportPath to the xml file):

Thanks,
Roy


(Roy Sela) #5

Sorry, used the wrong property - once i switched to sonar.coverage.jacoco.xmlReportPaths it worked :slight_smile:


(Michael Gumowski) #6

Thank you for letting us know! Can you just confirm explicitly that once you switched to the XML format with the proper property sonar.coverage.jacoco.xmlReportPaths (sorry, I forgot to mention it), then the coverage went back to normal?

Cheers,
Michael


(Roy Sela) #7

Yes it worked and the coverage is reported.

I will mention that it required us to modify some build processes in order to make it work, because we used to just run “sbt test” in order to run the tests and also the coverage, but that doesn’t take into affect the jacoco-sbt reporting settings (which is jacocoReportSettings := JacocoReportSettings(title = "Report Title", formats = Seq(JacocoReportFormats.XML)) in case someone else experience the same issue), so we need to start using “sbt jacoco” and change the sonar attribute accordingly - all this for various projects/teams that uses Java Play which up until now worked fine OOTB.

I’ve also tried to force jacoco-sbt to use the latest jacoco release (using dependencyOverrides ++= Seq( "org.jacoco" % "org.jacoco.core" % "0.8.3", "org.jacoco" % "org.jacoco.report" % "0.8.3" ), but apparently it wouldn’t work without further adjustments from the jacoco-sbt side as it made all of our tests to fail… I guess we’re stuck with XMLs until a new jacoco-sbt release will support jacoco 0.8.3.