Sonarqube not picking up test.exec file in monorepo

  • SonarQube Community Edition v7.9.1 build(27448)
  • SonarQube Scanner for jenkins v2.12
  • Sonar Quality Gates Plugin v1.3.1

Hi, I’m running into an issue with our Monorepo setup. I’m able to generate the Jacoco Reports & .exec file for each subproject. In our root settings.gradle.kts file I made a JacocoMergeReport task to consolidate all the execuation data file from each subproject and I do see it in the root dirctory ~/build/jacoco/text.exec.

Our project is built using Jenkins pipeline. After configuring the plugin by checking Enable injection of SonarQube server pointing to our server url. It’s not picking up the changes.


Welcome to the community!

Can you check which version of the Java analyzer you’re using? You’ll find it at Administration -> Marketplace.


Most of our services are built with Kotlin, but we do have a select few in Java

  • Java Analyzer 6.3 build(21585)
  • SonarKotlin 1.5.0 build(315)


It looks like you’ve upgraded the Java analyzer independently of your SonarQube version. You’re now at the point where the .exec reports are no longer recognized. You’ll need to switch to generating .xml reports. Note that you’ll probably need to update the relevant analysis parameter (value and key) too.


Looking at our build gradle, looks like we did enable xml for the reports. So for my understanding with the updated java analyzer version it no longer looks at the .exec file, but for jacocoTestReport.xml? And which analysis parameters would I need to update?


I could have maybe included this in my previous response:


I was missing “coverage” in “sonar.coverage.jacoco.xmlReportPaths” I’ll re-run and report back. Thanks

Would this work to get all the subprojects xml reports?
or do comma separated?
property("sonar.coverage.jacoco.xmlReportPaths", "${rootDir}/model1/reports/jacocoTestReport.xml,${rootDir}/model2/reports/jacocoTestReport.xml")


This is not my area of expertise, but the docs say path wildcards are supported by this property, so… it ought to work. That said. I’m truly not sure what the implications are in a multi-module/subproject context. Given that you’ve mentioned having a ‘build’ directory, I’m guessing Maven. So if what you’ve outlined doesn’t work, then defining them in the module poms should.