Code coverage missing for java project

SonarQube Server / Community Build
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    SonarQube 9.4.0-DE (dockerized) running from Jenkins maven project
  • what are you trying to achieve
    Determine amount of code coverage for tests in multi-component Java service
  • what have you tried so far to achieve this
    Earlier branch of project shows higher coverage than latest. Comparing output reveals no compelling reasons for this.
    Looking at final output from the scan stage of build pipeline, I see this detail:
04:44:44  [INFO] ------------------------------------------------------------------------
04:44:44  [INFO] Reactor Summary for danube-model-udf 1.12.184-SNAPSHOT:
04:44:44  [INFO] 
04:44:44  [INFO] danube-model-udf ................................... SUCCESS [01:50 min]
04:44:44  [INFO] udf-model-from-jenga ............................... SKIPPED
04:44:44  [INFO] udf-model-from-jenga-demo .......................... SKIPPED
04:44:44  [INFO] udf-model-parser ................................... SKIPPED
04:44:44  [INFO] udf-model-as-input ................................. SKIPPED
04:44:44  [INFO] udf-model-feedback ................................. SKIPPED
04:44:44  [INFO] udf-model-feedback-demo ............................ SKIPPED
04:44:44  [INFO] udf-model-integrate ................................ SKIPPED
04:44:44  [INFO] ------------------------------------------------------------------------
04:44:44  [INFO] BUILD SUCCESS
04:44:44  [INFO] ------------------------------------------------------------------------
04:44:44  [INFO] Total time:  01:51 min
04:44:44  [INFO] Finished at: 2022-05-09T11:44:44Z
04:44:44  [INFO] ------------------------------------------------------------------------

What is the explanation of the lines marked SKIPPED ? The Jenkins script includes these steps:

            stage('Static Analysis') {
              def xmlFilesInDir = findFiles(glob: '**/jacoco.xml')
              String filePaths = "-Dsonar.coverage.jacoco.xmlReportPaths="
              for (resultsFile in xmlFilesInDir) {
                filePaths += "${workspace}/${resultsFile},"
              }
              sh "mvn -B -e  ${filePaths} ${sonarOptions}  -Dsonar.login=${sonarToken}  sonar:sonar"
            }

Files collected include:

[build@jenkslave-service4 danube-model-udf_PR-224]$ find . -type f -name jacoco\.xml -ls
11547323 3440 -rw-r--r--   1 build    build     3519151 May  9 04:40 ./udf-model-as-input/target/site/jacoco/jacoco.xml
11672151    4 -rw-r--r--   1 build    build         335 May  9 04:40 ./udf-model-as-input/target/site/jacoco-aggregate/jacoco.xml
12720700   32 -rw-r--r--   1 build    build       29051 May  9 04:41 ./udf-model-feedback/target/site/jacoco/jacoco.xml
12720806    4 -rw-r--r--   1 build    build         335 May  9 04:41 ./udf-model-feedback/target/site/jacoco-aggregate/jacoco.xml
12849062   32 -rw-r--r--   1 build    build       29310 May  9 04:28 ./udf-model-feedback-demo/target/site/jacoco-aggregate/jacoco.xml
12718539  448 -rw-r--r--   1 build    build      457875 May  9 04:18 ./udf-model-from-jenga-demo/target/site/jacoco-aggregate/jacoco.xml
12717899  448 -rw-r--r--   1 build    build      457598 May  9 04:35 ./udf-model-from-jenga/target/site/jacoco/jacoco.xml
12718467    4 -rw-r--r--   1 build    build         337 May  9 04:35 ./udf-model-from-jenga/target/site/jacoco-aggregate/jacoco.xml
12849204    4 -rw-r--r--   1 build    build         336 May  9 04:42 ./udf-model-integrate/target/site/jacoco-aggregate/jacoco.xml
12847438   68 -rw-r--r--   1 build    build       69374 May  9 04:36 ./udf-model-parser/target/site/jacoco/jacoco.xml
12848592    4 -rw-r--r--   1 build    build         333 May  9 04:36 ./udf-model-parser/target/site/jacoco-aggregate/jacoco.xml
9183416    4 -rw-r--r--   1 build    build         157 May  9 04:10 ./target/site/jacoco-aggregate/jacoco.xml

And the coverage report looks like this:

danube-model-udf_PR-224_coverage
danube-model-udf_PR-224_coverage2658×1200 231 KB

However, the later branch analysis shows coverage report as:

danube-model-udf_PR-265_coverage
danube-model-udf_PR-265_coverage2684×1226 232 KB

2

Hi,

That’s a pretty limited segment of your logs. If that’s from coverage report generation, which is what I suspect, then your question is not “Why does SonarQube show lower coverage” but “Why was coverage report generation skipped”.

Care to provide a fuller log?

 
Ann

3

Attached log refers to the coverage report above for PR-224 (I presume Lines column refers to new lines in this branch?)
danube-model-udf_PR-224.log (50.9 KB)

4

Hi,

Thanks for the logs.

I see a couple interesting things. First, this set of lines, multiple times:

04:44:07  [INFO] Sensor JaCoCo XML Report Importer [jacoco]
04:44:07  [INFO] Importing 12 report(s). Turn your logs in debug mode in order to see the exhaustive list.
04:44:07  [INFO] Sensor JaCoCo XML Report Importer [jacoco] (done) | time=133ms

And second, that your 2nd screenshot in the OP is of a pull request, not a branch. In fact, on closer inspection, your screenshots seem to show two entirely unrelated PRs. So… I’m really not clear on your expectations.

 
Ann

5

Hi, Ann. Thanks for taking the time to look at these. What about the three lines mentioned is interesting? Is it that I need to have debug mode on to understand what’s going on? And secondly, we are typically analyzing the PRs, so they are not unrelated, but from the same code-base.
I’ll see if I can come up with more exact detail, but still need to understand if I am not invoking the analysis correctly. I’ve always observed the maven output showing the pattern above, but still getting coverage results.

6

Hi,

What’s interesting about those three lines is that they indicate the coverage reports are being read.

For PRs, I would expect the coverage numbers to be completely unrelated from one to the next. PRs report on new code. Each PR is going to have a different set of new code, and thus different coverage values.

 
HTH,
Ann

7

That explains a lot; typically we should be looking at the branch analysis for coverage, not the PR analysis. But we normally have branch builds disabled in Jenkins, and the report should include total coverage after merge, so it is still puzzling.