Calculating the coverage report (using Jacoco) of our project takes a long time. Because of this we have separate jobs for doing the normal sonar analysis and doing the sonar analysis with coverage. However, it seems that if both jobs submit the analysis to the same sonar project, sonar will take the values from the last job, but if the last job was the non-coverage job it will also reset the coverage counter to 0%. As the non-coverage job runs more often than the coverage job, the results would (most of the time) display that there is no coverage.
One solution would be to create two separate sonar projects, one for the coverage and one without, but this creates all of management issues as sonar issue will now have to be taken care of in both project as sonar sees no relation between them, which is something we want to avoid.
Another solution for this could be to share the jacoco coverage file produced by the coverage job with the non-coverage job. In that case the non-coverage job would pickup the last generated code coverage file. In this case the coverage will not always be up to date , but that’s ok, at least the last value will be shown instead of “0%”
My question: is the last solution perhaps possible using sonar itself? For example, is there a way of configuring sonar that certain values in the report (if not supplied, such as the coverage) should be replaced with their last known value?
Sorry, but what you want isn’t available on the SonarQube side.
You’ve already walked through what you could do instead.
Let me just add that if you retain and re-use a previous analysis’ coverage report, what you see for coverage in SonarQube is likely going to be confusingly inaccurate at some point.
Imagine that myMethod is on lines 15-20 when the coverage report is run. Then in the next analysis, with a re-used coverage report, there are some deletions, so myMethod is now on lines 12-17. But lines 15-20 will still be marked covered - including the vertical whitespace after the method that separates it from the next method.
IMO, the best option is two projects if you’re in SonarQube Community Edition, and two different branches if you’re not.
Let me just add that if you retain and re-use a previous analysis’ coverage report, what you see for coverage in SonarQube is likely going to be confusingly inaccurate at some point.
Thanks for pointing this out, that’s probably also a valid reason to not let sonar explicitly support showing an older report by retaining the old version if no newer was supplied.
IMO, the best option is two projects if you’re in SonarQube Community Edition, and two different branches if you’re not.
We are using the CE. This option creates an administration nightmare as everything needs to be done twice with risk for inconsistencies. Although one project could be considered as “ignore this - only to show code coverage” for example, but this leaves an ugly dashboard and also creates confusion.
So thanks for the input but we’ll be going with re-using an older report then, the temporary inconsistencies do not outweigh having to maintain two of the same project for us.