Code Coverage is showing at 0% in test environment after upgrade to 8.3
We recently upgraded our test environment to v8.3 and now the projects are not showing code coverage after analysis. Production is showing correct Code coverage on v7.9.1 for the same project. The test environment was recently restored with prod data so the projects are functionally identical.
We are using the sonar-jacoco plugin and I have tried specifying the xml report path using wildcards and explicitly but it’s still not working.
So I got this working if I specify an explicit path in the build arguments in Azure DevOps. We have multiple build servers and agents so this is not ideal.
Is there some sort of guide on using the wildcards for the path? I’ve tried “***.xml” but it doesn’t work.
The working path is “/data/AzureDevOpsAgents/A1/_work/57/s/CCReport43F6D5EF/jacoco.xml” and any variation of **/jacoco.xml or **/*.xml etc aren’t working.
I’ve also tried both of these in the build arguments in TFS as well as in the settings in Sonarqube and I get the same results. The wildcard approach isn’t working either way.
Kind Regards,
Devon.
WRT the Analysis logs, where are those? I’ve checked the ce.log file in the logs folder but I don’t see anything about the XMLReport path and I found the following in the access.log file…Are there any other logs that I need to check?
Build logs == analysis logs. And I’m reminded now that you provided that snippet in your original post. Sorry about that.
So… The reports exist at CCReport*/jacoco.xml. But analysis is looking for them under target. That implies to me that you’re doing a Maven analysis…? But not… generating the coverage reports via Maven?
Anyway, this looks like a bug in how those paths are read - unless the context for ** isn’t what you think it is. Could you provide - as text (purple on black at that font size is hard on the eyes!) - the analysis subset of your build log? Also, it might be helpful to add sonr.scanner.dumpToFile=[file name] to your analysis command line one time to see exactly what interpolated properties analysis is getting.
I’m confused by this log. There seem to be multiple Maven commands, all of them with analysis parameters, but only one that invokes the analysis task(?), and that with -Dsonar.jacoco.reportPaths=/data/AzureDevOpsAgents/A1/_work/57/s/CCReport43F6D5EF/jacoco.exec. I’m also confused about why the reports aren’t being dumped into the default location (as I implied earlier).
Anyway, I see analysis start to look for **/jacoco.xml on line 19205(!) and I see jacoco.xml actually generated(?) on line 20040.
Since you’re running this job as an upgrade test (-Dsonar.projectKey=com.electrabel.channels.web:bll-alerting:platformUpgradeTest) I suggest you turn off debug logging and whittle the job back to the bare minimum: clean, build, run tests & generate reports, analyze. Then it will be more apparent what’s actually going on.
I assume the fact that this is a multimodule project would account for the multiple maven commands?
The build pipeline only contains 2 steps, “Prepare Analysis on Sonarqube” and the “Maven pom.xml” build step so I’m not actually sure where the reports are being generated and how they’re being dumped to their location (this isn’t my project, I’m just assisting with the Sonar issue) or how I can whittle down the job any further.
I’ll have to try get the project dev on the line when he gets back from holiday next week.
I still haven’t had any luck sorting this issue. I’m not able to track down where the extra Maven commands are coming from. I see there are 3 in total but I’vew checked the pom.xml files for all of the associated modules and there’s nothing there. Is it at all possible that the Azure DevOps build step for “Prepare Analysis on Sonarqube” could be inserting extra config into the build somehow? I very much doubt it but I’m at my wits end right now.
Just to continue along this train of thought… regardless of what configuration I put in the pom.xml file, I find the following in the pom.xml on the build server after the build is complete. My config is still there as well, but this is added somewhere along the line during the build and I can’t figure out where or how.
I have searched all the pom.xml files of all the modules in the project and that particular config is nowhere to be found which is why I think it might be part of the build step.
Which version of the Maven task is displayed when you are executing your build ?
Where also do you set the path to the jacoco report ? In the UI ? Or as a parameter in your Prepare analysis configuration task ?
Thanks. Let’s try to stick into one single place (either the UI or the task configuration).
It should be better as well to at least specify a root path using one of the availble variable from the Build Pipeline, let’s say for example $(Agent.TempDirectory)/**/jacoco.xml something like this. Can you try that ?
but “$(System.DefaultWorkingDirectory)/**/jacoco.xml” does not work in the Sonar UI. Do those types of variables work in the Sonar UI?
This is a slightly better workaround than I had previously but we would still have to update dozens of builds with this and it would obviously be preferable to set it once in Sonar and then it’s done.
On another note @mickaelcaro, it seems like this fix only works on one of the projects. I’m trying the same strategy on another project with the missing code coverage issue and it’s not working. As you can see from the below logs, both builds read the code coverage successfully from the xml file located at “$(System.DefaultWorkingDirectory)/**/jacoco.xml” but the project on the left has code coverage in Sonar but the project on the right does not…
We’ve moved back to v 7.9.3 to see if the issue would be resolved by going back to the latest LTS version but we’re having the same issue. It’s important to note that our production environment is on 7.9.1 and is not having these issues.
