Fixing the root map in a SonarCloud project compared to an Azure Devops / GIT project

  • ALM used (Azure DevOps)
  • CI system used (Azure DevOps)
  • Scanner command used when applicable (private details masked)
      - task: SonarCloudPrepare@1
        displayName: 'Prepare analysis configuration'
        inputs:
          SonarCloud: 'SonarCloud'
          organization: 'organization'
          scannerMode: 'MSBuild'
          projectKey: 'projectKey'
          projectName: 'projectName'
          extraProperties: |
              sonar.exclusions=**/obj/**,**/*.dll
              sonar.cs.opencover.reportsPaths=$(Build.SourcesDirectory)/**/coverage.opencover.xml
              sonar.cs.vstest.reportsPaths=$(Agent.TempDirectory)/../testresults/*.trx
      - task: DotNetCoreCLI@2
        displayName: 'Build Solution'
        inputs:
          command: 'build'
          arguments: '-c $(buildConfiguration)'
          projects: 'some/subdirectory/Solution.sln'
      - task: DotNetCoreCLI@2
        displayName: 'Run Unit tests'
        inputs:
          command: 'test'
          arguments: '--no-build -c $(buildConfiguration) /p:CollectCoverage=true /p:CoverletOutputFormat=opencover --logger trx --results-directory $(Agent.TempDirectory)/../testresults'
          projects: 'some/subdirectory/test/UnitTests/UnitTests.csproj'
      - task: SonarCloudAnalyze@1
        displayName: 'Run SonarCloud code analysis'
      - task: SonarCloudPublish@1
        displayName: 'Publish SonarCloud quality gate results'

  • Languages of the repository (C#)
  • Only if the SonarCloud project is public, the URL
    • And if you need help with pull request decoration, then the URL to the PR too
      Private SonarCloud project

Hi all,

I need help with a SonarCloud project I’m setting up.
The issue is with the root folder in SonarCloud compared to the root folder in Azure Devops.

The setup in Azure is as follows:
some/subdirectory/Solution.sln
some/subdirectory/src/Project1.csproj
some/subdirectory/src/Class1.cs
some/subdirectory/test/UnitTests/UnitTests.csproj

What I see in Sonarcloud is the following:
src/Class1.cs : Code Smell More than 7 attributes in function

So it’s not showing the some/subdirectory maps. Generally speaking, this is fine. However, there are 2 issues which arise from this difference:

  1. When using the Pull Request functionality, the resulting comment is linked to the wrong file, e.g. “src/Class1.cs” which is not found, instead of “some/subdirectory/src/Class1.cs”
  2. The test coverage stays at 0.0%. While I’m not 100% certain, I’m pretty sure this is also because the paths in the test results do not correspond with the paths in SonarCloud.

So the question is simple, when running the build for some/subdirectory/Solution.sln , how can I let SonarCloud know to add the some/subdirectory/ map to the build results?

Thanks,

Arie.

Hey there.

How do you know that the wrong file is being linked? Is it only because no comments show up on your Pull Request?

Well, I see the Pull Request comment linking to the wrong file, as shown:


(for clarity, this should be “some/subdirectory/src/map/file.cs” for Azure Devops to find it)

In addition, when looking at code in Sonarcloud, I expect the subdirectory to show up, but it does not:

edit: The test coverage was indeed a separate, unrelated issue. Still, it would be nice if the Pull Request comments pointed to the right files.

Hey there.

I see what you’re saying. Let me ping somebody smarter than I am about this and see if we can get to the bottom of this.

Hey @arindam

Setting the analysis parameter sonar.verbose=true should reveal to us how the base directory is being derived. See here (relevant line surrounded by asteriks).

SonarScanner for MSBuild 5.4.1
Using the .NET Core version of the Scanner for MSBuild
Post-processing started.
16:31:24.058  16:31:24.031  Uninstalling target: /Users/colin/Source/dotnet-test-base/dotnet-test/.sonarqube/bin/targets/SonarQube.Integration.targets
16:31:24.058  16:31:24.058  sonar.verbose=true was specified - setting the log verbosity to 'Debug'
16:31:24.059  Loading the SonarCloud analysis config from /Users/colin/Source/dotnet-test-base/dotnet-test/.sonarqube/conf/SonarQubeAnalysisConfig.xml
16:31:24.059  Not running under TeamBuild
16:31:24.059  Analysis base directory: /Users/colin/Source/dotnet-test-base/dotnet-test/.sonarqube
Build directory: 
Bin directory: /Users/colin/Source/dotnet-test-base/dotnet-test/.sonarqube/bin
Config directory: /Users/colin/Source/dotnet-test-base/dotnet-test/.sonarqube/conf
Output directory: /Users/colin/Source/dotnet-test-base/dotnet-test/.sonarqube/out
Config file: /Users/colin/Source/dotnet-test-base/dotnet-test/.sonarqube/conf/SonarQubeAnalysisConfig.xml
16:31:24.06  Generating SonarCloud project properties file to /Users/colin/Source/dotnet-test-base/dotnet-test/.sonarqube/out/sonar-project.properties
16:31:24.089  Setting analysis property: sonar.visualstudio.enable=false
16:31:24.106  The supplied Code Analysis ErrorLog file is a valid json file and does not need to be fixed: /Users/colin/Source/dotnet-test-base/dotnet-test/.sonarqube/out/0/Issues.json
**16:31:24.123  Using longest common projects root path as project base directory: '/Users/colin/Source/dotnet-test-base/dotnet-test'.**
16:31:24.135  Dumping content of sonar-project.properties

Can you report back with these logs?

Hi @Colin,

No need, I have figured out what was wrong.

The Soundcloud project I made was not directly linked to the Azure project, as I also had an UI project which WAS linked to the Azure project.

Since then, I figured out the function and use of the Monodevelop projects. With that, I was able to set it up so that both the API and UI point to the same Azure repository, and with that, this problem has been fixed.

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