Sonarqube not processing opencover report

SonarQube Server / Community Build
1

Starting today a project of ours starting not to process opencover reports on a branch, even if it’s successfully parsed by the sonar scanner tool.

Sonar Scanner Logs:

INFO: Sensor C# Tests Coverage Report Import [csharp]

[688](MASKED#L688) WARN: Could not find any coverage report file matching the pattern './*/*.opencover.xml'.

[689](MASKED#L689) INFO: Parsing the OpenCover report [MASKED]\.\.\[MASKED]\coverage.opencover.xml

[690](MASKED#L690) INFO: Adding this code coverage report to the cache for later reuse: [MASKED]\.\.\[MASKED]\coverage.opencover.xml

[691](MASKED#L691) INFO: Parsing the OpenCover report [MASKED]\.\.\[MASKED].Tests\coverage.opencover.xml

[692](MASKED#L692) INFO: Adding this code coverage report to the cache for later reuse: [MASKED]\.\.\[MASKED].Tests\coverage.opencover.xml

[693](MASKED#L693) INFO: Sensor C# Tests Coverage Report Import [csharp] (done) | time=576ms

image
image1040×342 28 KB

  • The content of the xml files shows me that coverage exists
  • Tried to rerun the gitlab pipeline which executes the scan -no success-
  • Another project with the same scanner and setup (c# - opencover) runs good
  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    • Sonarqube Version: 8.2

I don’t know where to search for the issue

2

hi @geissbnj, apologies for the delay.

do you still have the problem?

3

Hi Benjamin, I had a similar problem, I discovered that if I use a relative path or a pattern as you used, the sonar scanner didn’t find the coverage report, but when I defined a absolute path the sonar scanner managed find my coverage report. We used Azure DevOps and I defined the path this way (considering that I have available a variable called Build.SourcesDirectory):

sonar.cs.opencover.reportsPaths=$(Build.SourcesDirectory)/testes/coverage.opencover.xml

I hope that it help you

1 Like
4

hey, tried adjusting the path but it does not help. But it was worth the try.

5

I still have the problem, jep. Sorry for the delay. It’s vacation time in germany :slight_smile:

6

hi @geissbnj

:smiley:

To investigate further, we’d also need the verbose logs. Please add the sonar.verbose=true property at the BEGIN step and give us the logs of the BEGIN and END steps. Like SonarScanner.MSBuild.exe begin /k:"MyProject" /d:sonar.verbose=true.

If you don’t want to share the logs, you can look inside for the following possible issues:

At the end, it says how many reports in aggregated. If it’s 0, we need to dig into finding out why.

DEBUG: Analyzing coverage after aggregate found '0' coverage files.
DEBUG: The total number of file count statistics is '0'.
INFO: Sensor C# Tests Coverage Report Import [csharp] (done) | time=1309ms

Depending on how you configure your analysis, the indexed files by the scanner may have different paths than the ones in the report. That can happen if you run the analysis from one folder (and the scanner sets a certain base directory) and generate the coverage in a separate step, in a separate folder. See this topic that had this problem.

To check which is the base path look for this log:

DEBUG: The current user dir is '<PATH>'.

To check the path of the indexed files look for this log:

DEBUG: '<PATH\FILE.cs>' indexed with language 'cs'

Then if the paths inside the coverage file differ from the path of the indexed files, look for this log:

INFO: Parsing the OpenCover report <FILE PATH>
DEBUG: Skipping file with path '<PATH\FILE.cs>' because it is not indexed or does not have the supported language.

In short: all commands need to be run from the same folder (to get the same paths).

1 Like
7

I’m running into the same issue with an OpenCover report generated by Coverlet.

/Relative/Path/To/File.cs indexed with langauge ‘cs’

skipping the fileId ‘38’, line ‘482’, vc ‘1’ because file ‘/var/lib/bamboo/xml-data/build-dir/ED-ENGINE-RDT2/src/blah/File.cs’ is not indexed or does not have the supported language

Seemingly because the paths in the coverage file are absolute but the files are being indexed maybe.

8

Hello @DH1512 and welcome to the community

Are you running the analysis from the same folder where you ran the code coverage tool?