Zero code coverage for Android app in SonarCloud + Github setup

We have an integration SonarCloud + Github for Kotlin android project which is processing fine, branches, PRs verification etc works.

Basic dashboard with non-zero values, all good:

According to documentation for test&execution I followed sample and created properties file in root folder:

coverageReport.xml is generating by jacoco and extracted from build folder and properly placed in specified location, even sonar sees it:

It was generated properly and contains coverage info:

Issue is that with this whole setup code coverage tab is empty:

Hello @dilix

Welcome to the community.
FIrst of all it’s very easy to post screenshots inline in our forum (just copy the image and paste in the thread), so I encourage you do to so and not use external web site, this is more difficult to follow.

Now about your problem. There’s a lot of misunderstanding on how to import coverage:

  • The file where you have to add the coverage property is not but in your build.gradle file.
  • The fact that you see the coverageReport.xml in the SonarQube UI is not a good sign, it’s a bad one. It means that during the scan SonarQube has seen the file as a source file (XML can be source code), not as a test report.
    The property sonar.sources should define locations that will not catch the coverage report. So you should store the report in a location that is not part of sonar.sources or use sonar.exclusions to exclude that file to be considered a source file.

Please fix the above as a first step, then we’ll see where you are to define the next step.


Hey @OlivierK thx a lot for your input!

Maybe you could shed some light on the initial need :slight_smile:

I know that storing build artificats right in code is not a good way to go but I haven’t found final solution yet.

What we need is to show those reports (test coverage, overall tests etc) inside github PRs and SonarCloud itself.

We already have github + sonarcloud integration in place with auto integration without single mention of sonar in gradle or wherever else. Since we already have it and it works I just wanted to add test + coverage info inside this setup.

The question is: could I somehow let sonarcloud know about test coverage report (which could be generated via CircleCI or GithubActions)?
Or do I need to remove all default auto integrations and make :sonar from sonarQube plugin be a part of build step inside CI script with all relevant configs?


Hello Dmitry,

I did not directly address the initial need because that would have been too much feedback at once, and sometimes the information does not get through when you provide too much of it.

I will give a last comment about:

You don’t have to store in SonarQube exactly the same files that you store in GitHub. I have nothing against storing your test reports in GitHub, it can make sense (to track changes), but it does not make sense to do the same in SonarQube, so you can exclude that particular file.

Now, how to have SonarQube interpret this file as the test report and not a mere XML file.
Simply by setting the property sonar.coverage.jacoco.xmlReportPaths=sdk/coverageReport.xml in your project analysis settings (either in the properties section of your build.gradle or as -Dsonar.coverage.jacoco.xmlReportPaths=sdk/coverageReport.xmlin your gradle command line

Let me know if you succeed or not.
If it still does not work, please send the *full log of your gradle invocation in debug mode (gradlew -d) for inspection


PS: Edited to fix the coverage file path

I don’t run sonar task as gradle step, we use auto analysis of SonarCloud with Github.
Afaik this all settings works in case of manual run of sonar plugin from gradle am I right?

@OlivierK spent more time realising concept - all good, it works.
I’ve disabled auto analysis and run sonarqube gradle plugin which also takes gen code coverage report on prev. step.

Thx a lot for support!

However I also myself did not realize that you were using the autoscan feature.
I guess that this should work too. I will check that and will update that thread.

It will work @OlivierK but in this case you need a stable path to coverage, meaning it could be tricky to regenerate codecoverage and make sure that this report is up to date.

Having granular build steps and take over the control by manual test is more predictable :slight_smile: You could set coverage path and other setting during manual build.

But still manual scan + github integration works. This integration triggers all features like comments in PR after sonarqube task finishes.

@dilix Could you please share the configuration which you use for the SonarQube plugin in your Gradle setup? Thx.