We are using Azure DevOps.
SonarScanner version: 4.23.0.
SonarQube version: 8.7.1
I have a huge project with 50+ projects (C#). I run dotCover to get a report, then transform this report into “Generic Test Data” format and import it to SonarQube. All the projects, except one, have codecoverage next to it under “Code” tab. I checked the report we upload to Sonar, and it does have files from the project.
Interesting thing is that folder, the project lives under, differs from project name. Could this be a root cause?
First, your version is past EOL. You should upgrade to either the latest version or the current LTS at your earliest convenience. Your upgrade path is:
8.7.1 → 8.9.2 → 9.1 (last step optional)
Regarding your actual question, let me start by saying that C# analysis, and particularly C# coverage is not my forte. But I notice this:
You know that dotCover reports are natively supported, right? The parameter is sonar.cs.dotcover.reportsPaths (docs).
Sorry, I know that doesn’t directly address your question, but it could simplify your workflow. Separately, I’ve tagged this thread to hopefully draw more expert attention. And in the meantime, perhaps you could provide more details about the lone project without coverage?
Unf, version patching is not under my control (we are a big enterprise and SonarQube instance is supported by dedicated team).
Regarding dotCover native support: yes, I know that, but historically Generic Test Data format was chosen because we needed reports in different formats and this is possible only using dotCover in combination with reportGenerator tool. Now, when this constraint is eliminated, we cannot switch to dotCover native report since it is showing different numbers (because SonarQube uses its own formula when calculating coverage based on Generic Test Data format). And since discrepancy is too big (up to 20%) - our management won’t buy this )).
I already found the root cause: the project had a legacy Test Explorer Service tag {82A7F48D-3B50-4B1E-B82E-3ADA8210C358} and was treated by Sonar as TEST project.
If you don’t mind, I’ll ask for a bit different clarification (related to coverage)
In my project, coverage is calculating incorrectly (in my opinion).
We are using Generic Test Data Format for coverage. According to the documentation, each record may have 2-4 attributes (lineNumber, covered, branchesToCover, coveredBranches). The last 2 are optional, and they do not exist in the report we are generating.
I know that for such cases, Sonar uses the following formula: Coverage = (CT + CF + LC)/(2*B + EL).
From what I can see, if branchesToCover and coveredBranches do no exist - this formula transforms into CoveredLines/LinesToCover (correct me if I’m wrong).
And here is what we have for our project:
Could you please explain to me how Sonar gets 62%? According to my calculations it should be around 47 (and the original dotCover file, that we are generating Generic Test Data file from, has the same value) (transformation is performed using reportgenerator tool).
Hello @Sergey_Machel,
Humm, indeed the results are inconsistent. SonarQube should report 47.6%, without any doubt
The first thing I am thinking about is a corrupted Elastic Search index. The way to verify that would be to regenerate the index, but that’s a rather impactful procedure on large platforms:
Stop SonarQube
Wipe the index in <SONARQUBE_HOME>/data/es7 (or es6 depending on your version)
Restart SonarQube
Wait for the index to be rebuilt
I doubt of any other option but there ways to narrow down the problem to the module/dir/file where the problem happens.
You can recursively check at the coverage level for each subcomponent of the problem and recursively down up to files, to hopefully find that all but one or a few components have OK coverage.
Looking at the nature of the subcomponent where the coverage is inconsistent can help understanding what’s special that would break coverage calculation.
Checking recursively is not convenient from the UI but you can do that fairly easily with the APIs:
returns the coverage data of all the subcomponents/subdirs of the project, along with the subcomponent key <projectKey>:<dirOrFilePathRelativeToProjectRoot>.
You check the values, and recurse on subcomponents whose 3 metrics are not consistent to hopefully narrow down the culprit (with another call to api/measures/component_tree?ps=500&s=qualifier,name&component=<subcomponentKey>&metricKeys=coverage,lines_to_cover,uncovered_lines&strategy=children)
