Sonar Code Coverage dropped after dotnet version upgrade to V10

SonarQube Cloud
1
  • ALM used - Azure DevOps
  • CI system used - Azure DevOps

We’ve recently upgraded the dotnet version to V10 for backend applications and post that noticing code coverage dropped to 0% or so and before upgrading it was around 80% or more. We are using all 3 tasks from sonar in ADO CI pipelines - Prepare Sonar Analysis Configuration, Run Sonar Cloud Analysis and Publish Quality Gate Result.

  1. We are using opencover format for coverage details.
  2. coverlet. Collector and Microsoft.NET.Test.Sdk packages are also updated.
  3. No changes in pipeline template and sonar is able to identify the coverage xml file and parsing as expected.
  4. Tried with sonar v4 and dotnet clean tasks as well before running sonar steps.
  5. Tried Cobertura format of coverage report as well for testing.

Not able to find out the root cause and solution for the code coverage drop issue.

2

The pipeline log should say something regarding the coverage. I had problems with the dotnet deterministic build which uses filenames starting with “/_/”, which SonarQube seems not to support Support deterministic paths for C# coverage

That was visible in the pipeline logs like

INFO: Imported coverage data for 5308 files
INFO: Coverage data ignored for 653 unknown files, including:
/_/Apps/Project/MyFile.cs
3

Run sonar analysis pipeline log before update -

INFO: Parsing the OpenCover report /home/vsts/work/_temp/0ffccc6a-6242-4720-bdaa-d8c382117fae/coverage.opencover.xml

INFO: Adding this code coverage report to the cache for later reuse: /home/vsts/work/_temp/0ffccc6a-6242-4720-bdaa-d8c382117fae/coverage.opencover.xml

INFO: Coverage Report Statistics: 233 files, 233 main files, 233 main files with coverage, 0 test files, 0 project excluded files, 0 other language files.

INFO: Sensor C# Tests Coverage Report Import [csharpenterprise] (done) | time=462ms

Run sonar analysis pipeline log after update -

INFO: Parsing the OpenCover report /home/vsts/work/_temp/d5fa8ada-4a53-445d-a650-09f5b4badc38/coverage.opencover.xml

INFO: Adding this code coverage report to the cache for later reuse: /home/vsts/work/_temp/d5fa8ada-4a53-445d-a650-09f5b4badc38/coverage.opencover.xml

INFO: Coverage Report Statistics: 89 files, 89 main files, 89 main files with coverage, 0 test files, 0 project excluded files, 0 other language files.

It’s clear that sonar is able to see a smaller number of file post upgrade.

The command in build project and run test step is as below -

/opt/hostedtoolcache/dotnet/dotnet test /home/vsts/work/1/s/LI.MultiSpecies/MultiSpecies.MovementService.Tests/MultiSpecies.MovementService.Tests.csproj --logger trx --results-directory /home/vsts/work/_temp --configuration Release --collect:XPlat Code Coverage – DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=opencover

On rerunning the old pipeline before the dotnet upgrade sonar reflects the code coverage % correctly.

4

I wouldn’t necessarily assume that the SonarScanner is seeing fewer files. Have you checked that the contents of the actual coverage reports are identical? Could you export the coverage report file from your pipeline and inspect it manually? At the end of the day, the coverage reported by the SonarScanner is based on what the report says.

5

Yes, inspected both of the coverage files manually and found that the old coverage report shows 2 modules in coverage.opencover.xml file whereas the new report shows only 1 module. And the test project has references to these 2 csproj files.

6

In that case, you should investigate what has happened in your test running/report generation process to cause this change, perhaps in relation to the dotnet upgrade. I cannot help you with this, this is outside of the sonar scanner’s scope.