dotCover code coverage not showing in SonarCloud

mkoziel2000 · October 22, 2021, 6:39pm

We are switching to use Linux build agents in Teamcity (via Kubernetes containers), which required pulling in the dotnet global tool of sonarscanner to help facilitate getting Sonar integrated with our .NET Core projects. Everything works except for the coverage. I’m at a loss as to whats happening. We have it all working with our windows agents using the same coverage reporting technique, but they are using an older sonarscanner binary to relay the information up to sonarcloud.

We are using the method of aggregating all of the *.dcvr into a merged file and then creating an HTML coverage file from that using the “merge” and “report” verbs on the tool dotnet-sonarscanner. Looking at the converage.html file, all of the coverage data is there and ready for ingestion. It just doesn’t seem to be getting reflected in SonarCloud. I do not see any issues when sonar-verbose=true is set. The sonar scanner seems to detect the existence of the coverage.html file that we generated. However, it looks like the sonar tooling itself is not transmitting the results up into SonarCloud. We have the sonar.cs.dotcover.reportsPaths=coverage.html configured to force the tooling to look at the coverage file that we generated.

Any thoughts on what else to check? Is this a bug in the scanner? I’ve already had a look at the troubleshooting wiki article that was published back in February in response to others having similar issues with .NET Core & dotcover.

Claire_Villard · October 25, 2021, 3:19pm

Hi @mkoziel2000,

Could you please post the full logs produced during the scanner execution, with sonar.verbose=true?

The exact command used to run the scanner may also help.

HTH
Claire

mkoziel2000 · October 25, 2021, 4:59pm

sonarscan-issue.log (373.6 KB)

mkoziel2000 · October 25, 2021, 5:26pm

Here is the powershell used to kick off the scanner.

/root/.dotnet/tools/dotnet-sonarscanner begin /d:sonar.verbose=true /d:sonar.host.url="https://sonarcloud.io/" /d:sonar.login="*******" /d:project.home=. /k:"https:__bitbucket.org_pfllink_ops-cicd-pipeline-creation-app.git" /n:"htops-cicd-pipeline-creation-app" /v:"1.0.0-beta.17" /d:sonar.cs.dotcover.reportsPaths="/opt/buildagent/work/d3bec01497236ba2/coverage.html" /d:sonar.cs.nunit.reportsPaths="/opt/buildagent/work/d3bec01497236ba2/nunit-results.xml" /o:pfllink /d:sonar.exclusions=**/*.java,**/node_modules/**,**/jquery*.js,**/angular*.js,**/knockout*.js,**/bootstrap*.js,**/underscore.js,**/ng-*.js,**/grid.locale*.js,**/respond.matchmedia.addListener.js,**/respond.js,**/modernizr-*.js,**/popper*.js,**/*test.cs,**/*tests.cs,**/bootstrap*.css,**/angular*.css,**/NLog.xsd,**/animate.css,**/font-awesome*.css,**/jquery*.css,**/jsnlog.js,**/Content/themes/base*/**,**/dataTables.*,**/jquery.jqGrid/**,**/angular-ui/**,**/require.js,**/Content/font-awesome/**,**/Content/NonNuget/sfds/**,**/Content/PDFjs/**,**/Content/tether/**,**/Content/NonNuget/daterangepicker.js,**/Content/ngAnimate.css,**/ui-bootstrap*.css,**/font-awesome/**,**/Scripts/NonNuget/**,**/Scripts/PDFjs/**,**/Scripts/sheetjs/**,**/Scripts/tether/**,**/Scripts/umd/**,**/Scripts/NonNuget/daterangepicker.js,**/Scripts/lodash.js,**/Scripts/moment*.js,**/Scripts/mapping.fp.js,**/Scripts/jsonr.js,**/Scripts/FileAPI.js,**/Scripts/core.js,**/Scripts/bootbox.js,**/Scripts/mapping.fp.js,**/Scripts/ai.*.js,**/Scripts/adal.js,**/Scripts/adal-angular.js,**/MarketingPlatform.*.Content/angucomplete-alt.css,**/MarketingPlatform.*.Content/ngAnimate.css,**/PMC.Plugin.MarketingPlatform.Marketo/Scripts/**,**/Content/PerfectScrollbar/**,**/Scripts/cldr/**,**/Scripts/globalize/**,**/Scripts/Chart.js,**/Scripts/Chart.PieceLabel.js,**/Scripts/FileSaver.js,**/Scripts/globalize.js,**/Scripts/http-auth-interceptor.js,**/Scripts/ng-storage.js,**/Scripts/r.js,**/Scripts/lodash.core.js,**/Scripts/PerfectScrollbar/**,**/external-libs/**

mkoziel2000 · October 27, 2021, 9:34pm

I still have not found a fix for this. Is this a bug or limitation with using SonarCloud with linux-based sonar scanner?

Claire_Villard · October 28, 2021, 6:36am

Hi @mkoziel2000

It seems the coverage files are correctly generated and picked by the sonar scanner.
There is no limitation of any scanner, the coverage is a main feature that is natively supported on all scanners.
Could you please give me the project key if it is public, or try to build a public reproducer for us to investigate further?

mkoziel2000 · November 1, 2021, 6:00pm

I just made the one project that is reproducing this visible. Its just a shell app to help demonstrate the issue we are seeing. https://sonarcloud.io/project/overview?id=https%3A__bitbucket.org_pfllink_ops-cicd-pipeline-creation-app.git

Claire_Villard · November 3, 2021, 4:06pm

Hi @mkoziel2000

The coverage report contains data for only 5 files, 3 main files and 2 test files.
The 3 main files are excluded because they are detected as being generated code:

[01:02:55] :	 [Step 6/8] 08:02:55.223 DEBUG: File '/opt/buildagent/work/d3bec01497236ba2/CICDPipelineCreationApp/Models/PipelineDefinition.cs' was recognized as generated
[01:02:55] :	 [Step 6/8] 08:02:55.223 DEBUG: File '/opt/buildagent/work/d3bec01497236ba2/CICDPipelineCreationApp/Models/PipelineCreationResponse.cs' was recognized as generated
[01:02:55] :	 [Step 6/8] 08:02:55.223 DEBUG: File '/opt/buildagent/work/d3bec01497236ba2/CICDPipelineCreationApp/Controllers/CicdApi.cs' was recognized as generated

Even if analysis on generated code is usually not advised, because it often generates issues that can’t be fixed by the developers, you can disable the automatic exclusion using the solution of this other thread.

mkoziel2000 · November 4, 2021, 4:39pm

Thanks for spotting that. I added the “/d:sonar.cs.analyzeGeneratedCode=true” to the scan command to force analysis of all the files…that seem to allow the coverage to work now. Is there a doc that describes what the rules are for how Sonar detects a generated code file? We support development efforts whereby we initially generate code from OpenApi contracts as a bootstrapping step and then modify it from there. This is going to continue to trip us if we don’t know what we need to tweak in the file to get Sonar to analyze it properly.

Claire_Villard · November 4, 2021, 5:06pm

With the analysis of generated code enabled at the project level, you shouldn’t be bothered again with this behavior. Since you are supporting code that comes from a generator and is then changed, I think it is the right way to proceed.

The files have been classified as generated because they contain a comment line starting with: Generated by. If you remove that line on the generated files you maintain, they should not be excluded even if you disable the global project property.
There is no official documentation of the criterias, but the .NET analyzer is open source, you can see the list of criterias here.

If the problem is solved, could you please mark my post as the solution?

mkoziel2000 · November 4, 2021, 6:15pm

Code file is just as good as documentation in my book. thanks for the help in getting to the bottom of this one.

system · November 11, 2021, 6:16pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.