After server upgrade to 2025.1.1.104738 metrices are lost

SonarQube Server / Community Build
, , ,
1

Hello everyone,
we have a problem in that we can no longer see some of the metrics after upgrading to server version 2025.1.1.104738. We haven’t changed the way we generate the coverage/trx files. All other metrics are available except for these. Can anyone help me with this?

Here a screenshot of the missing metrices:

missingtestsincoverage
missingtestsincoverage266×669 7.22 KB

For a better understanding: The entire block in the red rectangle is no longer there.

The created *.trx file contains at the end a summary like this

  <ResultSummary outcome="Completed">
    <Counters total="238" executed="238" passed="238" failed="0" error="0" timeout="0" aborted="0" inconclusive="0" passedButRunAborted="0" notRunnable="0" notExecuted="0" disconnected="0" warning="0" completed="0" inProgress="0" pending="0" />
  </ResultSummary>
  • ALM used Azure DevOps
  • CI system used Azure DevOps
  • Scanner command used:
...
  - task: SonarQubePrepare@7
    displayName: 'Prepare analysis on SonarQube'
    inputs:
      SonarQube: 'SonarQube-Cloud'
      projectKey: 'ProjectKey'
      projectName: 'ProjectName'
      projectVersion: '$(Build.BuildNumber)'
      extraProperties: |
        sonar.cs.opencover.reportsPaths=**/*.opencover.xml
        sonar.cs.vstest.reportsPaths=**/*.trx
	    sonar.exclusions=**/SomeExclusion.cs
	    sonar.coverage.exclusions=**/SomeCoverageExclusion.cs
    condition: succeeded()

...

# Some task: DotNetCoreCLI@2 where we do the builds for the service and unit tests.

...

  - task: DotNetCoreCLI@2
    displayName: 'Execute uTest'
    inputs:
      command: test
      projects: '**/_uTest.csproj'
      arguments: '--no-build --logger trx --results-directory $(System.DefaultWorkingDirectory)/TestResults -c ${{parameters.Configuration}} -p:CollectCoverage=true -p:CoverletOutputFormat=opencover -p:CoverletOutput=Coverage/'      
      publishTestResults: false

  - task: PublishTestResults@2
    displayName: 'Publish Test Results'      
    inputs:
        testResultsFormat: VSTest
        testResultsFiles: '**/*.trx'
        testRunTitle: 'Unit Tests'
        mergeTestResults: true

  - task: reportgenerator@5
    displayName: ReportGenerator
    inputs:
      reports: $(System.DefaultWorkingDirectory)/Test/uTest/Coverage/coverage.opencover.xml
      targetdir: $(System.DefaultWorkingDirectory)/TestResults/CoverageResults
      reporttypes: HtmlInline_AzurePipelines;Cobertura
      publishCodeCoverageResults: true  

  - task: SonarQubeAnalyze@7
    displayName: 'Run SonarQube'  

  - task: SonarQubePublish@7
    displayName: 'Publish SonarQube (Quality Gate Result)'	   
...
  • C#, powershell
  • Error observed: There are no obvious erros in the logs
2

Hi,

Can you share your analysis log, please?

Share the Scanner for .NET verbose logs

  • Add /d:"sonar.verbose=true" to the…
    • SonarScanner.MSBuild.exe or dotnet sonarscanner begin command to get more detailed logs
      • For example: SonarScanner.MSBuild.exe begin /k:"MyProject" /d:"sonar.verbose=true"
    • “SonarQubePrepare” or “SonarCloudPrepare” task’s extraProperties argument if you are using Azure DevOps
      • For example:
        - task: SonarCloudPrepare@3
    inputs:
      SonarCloud: 'sonarcloud'
      organization: 'foo'
      scannerMode: 'dotnet'
      projectKey: 'foo_sonar-scanning-someconsoleapp'
      projectName: 'sonar-scanning-someconsoleapp'
      extraProperties: |
        sonar.verbose=true
  • The important logs are in the END step (i.e. SonarQubeAnalyze / SonarCloudAnalyze / “Run Code Analysis”)

Share the msbuild detailed logs

MsBuild.exe /t:Rebuild /v:d

or

dotnet build -v:d

 
Thx,
Ann

3

(post deleted by author)

4

Hi,

Thanks for the log. In it, I see the test execution report being parsed, starting at line 3203, and then starting at 3442, there are a bunch of lines that look like this:

2025-04-28T06:10:04.3675884Z 06:10:04.363 DEBUG: Test method Collectors_uTest.Collectors_uTest.AzureDevOpsProjectRepositoriesCollectorTest.Execute_IsNull_GitRepo cannot be mapped to the test source file. The test will not be included.

So it looks like analysis is skipping reporting on tests that it didn’t find in the project. So I suppose the paths in the execution report don’t match the paths analysis is seeing. Does that make sense?

 
Ann

5

Hi,

thanks for the reply. I think you’re basically right. Sonar can’t find any tests that are referenced in the *.trx file.

We noticed that the SonarQubeAnalyze task reads the test files (in log line 92), but we don’t see .sonar.tests set anywhere. It is literally not there. Shouldn’t all files that match a certain pattern (i.e., test files) be set there? We already tried setting the path to the tests in the SonarQubePrepare task, but without success.

  - task: SonarQubePrepare@7
    displayName: 'Prepare analysis on SonarQube'
    inputs:
      SonarQube: 'SonarQube-Cloud'
      projectKey: 'ProjectKey'
      projectName: 'ProjectName'
      projectVersion: '$(Build.BuildNumber)'
      extraProperties: |
        sonar.cs.opencover.reportsPaths=**/*.opencover.xml
        sonar.cs.vstest.reportsPaths=**/*.trx
	    sonar.exclusions=**/SomeExclusion.cs
	    sonar.coverage.exclusions=**/SomeCoverageExclusion.cs
        sonar.tests=$(Build.SourcesDirectory)/Test/uTest/Collectors_uTest/*Test.cs
    condition: succeeded()

If you have any ideas that could help us, we would appreciate it.

*d

6

Hi,
At least for this one project, we were able to find the cause of the error. You were right in assuming that the tests could not be found.

The problem is the use of this tag <SonarQubeExclude>true</SonarQubeExclude> in the test project (*.csproj) at the project level. Once this tag is removed, the scan works as it did before the server update.

Apart from the fact that the scan works again, there is the unpleasant side effect that the test projects are also analyzed by SonarQube.

Is there a way to avoid this without crippling the scan?

Using sonar.exclusions= in the SonarQubePrepare task is also not a solution, as it triggers the same behavior as <SonarQubeExclude>true</SonarQubeExclude>.

Cheers
*d

7

Hi @Daniel2.0,

We do analyze test code, but with a more limited set of rules. May I ask what the problem is when we analyze test code?

Denis

1 Like
8

Hi @denis.troller,

Theoretically, there is no reason not to do this. However, I would like to point out two things:

  1. It should be an option to choose whether or not the test code should be analyzed.
  2. It represents a breaking change. Before the major server upgrade, this was not a problem. The test code could be excluded from the Sonar analysis, and the actual product code was still analyzed correctly.

Point two in particular is really hitting us hard. We have a medium number of teams that now have a real problem. We tested it on a really small product (removing exclusions) and the Sonar rules that are applied to the test code are really picky.

Is there a way to apply a rule set (containing no or only a few rules) to the tests themselves? Or is there even a way to restore the old behavior?