Too much findings - Azure Devops Pipelin driven Sonarcloud analysis in MonoRepo

Hi,

  • we are running Sonarcloud from AzureDevops on our monorepo
  • we setup a monorepo in sonarcloud with multiple subrojects
  • every subproject has its own build pipeline using its own ‘projectKey’
  • we are running scannerMode: "MSBuild"

Builds are having Sonar Issues from all over the monorepo, so “subproject-a” is finding/showing issues from “subproject-b”.

How is this possible or what are we doing wrong ?

steps:
  - checkout: self
    fetchDepth: ${{ parameters.sonarFetchDepth }}
  - task: SonarCloudPrepare@1
    inputs:
      SonarCloud: "SonarCloud XY-Development"
      organization: "${{ parameters.sonarOrganization }}"
      scannerMode: "MSBuild"
      projectKey: "${{ parameters.sonarProjectKey }}"
      projectName: "${{ parameters.sonarProjectName }}"
      sources: "${{ parameters.projectPath }}\\${{ parameters.sources }}"
      tests: "${{ parameters.projectPath }}\\${{ parameters.tests }}"
      projectBaseDir: "${{ parameters.projectPath }}"
      verbose: true
      extraProperties: |
        sonar.cs.vstest.reportsPaths=$(Agent.TempDirectory)\**\*.trx
        sonar.cs.vscoveragexml.reportsPaths=$(Agent.TempDirectory)\**\*.coveragexml
        sonar.verbose=true

None of these key/value pairs are read (they are not valid), nor should their analysis parameter equivalent be needed if, for example, only the specific subproject is being built in the pipeline (and no others).

If further exclusions/inclusions need to be carried out after, they can be done by adjusting the Analysis Scope with sonar.exclusions and sonar.inclusions

ok, thx so i removed all key/values you mentioned

But i’m still curious how to tell the “SonarCloudPrepare@1” which *.sln to use for src folder discovery.

And it also still doesn’t work - “subproject-a” gets processed and at the end it has findings from “subproject-b”

By only building that solution in between the SonarCloudPrepare and SonarCloudAnalyze step!

Maybe you can post your full Azure Pipelines YML.

ok, i think we found our problem here.

Our multiple MSBuild-Projects have each their own Solution File and in that SLN Files there are other projects linked with some GUIDs.

The sonar scanner shows this GUIDs all listed under “- sonar.modules” and analyses them modules/projects one after another.

I think we could work here with some exclusions but the way would be in my opinion to ged rid of those solution file references where they are not needed.

Or is there some special property in sonarcloud for this scenario - something like “omitModules” ?

Nothing so specific, only the inclusions/exclusions I mentioned earlier.

This sounds like the way to go (and it should speed up your builds!)

So we ended up using CLI Scanner for every build (regardless if .net, JS or something else) - because it seems its the only thing thats working properly with Azure Devops and Sonarcloud.

scannerMode: "MSBUILD"

does not work here:

  • it takes sources from anywhere of the monorepo
  • if we specifiy “src” and “tests” ist gives errors like “can’t be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files”, although src and test folder is on the same level.
  • projectfolder
    • src
    • tests

You will not be able to receieve any feedback on .NET code if you use the Scanner CLI. The Scanner for .NET must be used.

It sounds like you’re defining sonar.sources manually somewhere. You should not, and rely on the build only building what you need (and, using inclusions/exclusions for further filtering)