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 .sonarcloud.properties 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.
Maybe you could shed some light on the initial need
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?
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
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.
@dilix,
Great!
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 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.
