Wrong "Base Dir" for SonarCloud analyze task (randomly)

SonarQube Cloud
,
1
  • ALM: Azure DevOps
  • CI system: Azure DevOps
  • Scanner command:
  - task: SonarCloudPrepare@1
    displayName: Prepare SonarCloud analysis configuration
    inputs:
      SonarCloud: SonarCloud
      organization: $(sonarOrganization)
      scannerMode: MSBuild
      projectKey: $(sonarOrganization)_$(sonarProject)
      projectName: $(sonarProject)
      extraproperties:
        sonar.exclusions=src/**/Resources/*
        sonar.cpd.exclusions=**/Migrations/*,src/**Persistence/Migrations/*,src/*.DataSeeder/SeederImplementations/**
        sonar.coverage.exclusions=**/Migrations/*,src/*.DataSeeder/**,src/*.Api/Program.cs,src/*.Domain/Exceptions/**Exception.cs,src/**Persistence/Migrations/*,src/**/Persistence/Migrations/*
        sonar.coverageReportPaths="$(Build.SourcesDirectory)/coveragereport/SonarQube.xml"

  // build

  - task: SonarCloudAnalyze@1
    condition: succeededOrFailed()
    displayName: SonarCloud analyze

  - task: SonarCloudPublish@1
    displayName: SonarCloud publish Results
    condition: succeededOrFailed()
    inputs:
      pollingTimeoutSec: '300'
  • Languages: C#
  • Error observed:

Sometimes we get a lot of pull requestion annotations from Sonar for some of our repositories. With “a lot” I mean all build warnings are commented, instead of just for “new code”.

Also the comments are created on the wrong path:
“This file no longer exists in the latest pull request changes. It may have been moved or deleted.”
It has a prefix /azp/_work/1/s/, that shouldn’t be there (which is coming from the Azure Pipeline agent)

We only observed this issue in our Azure Function repos.

Today I could narrow it done one step more: it seems to be related to a specific nuget package reference.
I had at least three repositories with the following change:

image
image1134Ă—142 7.71 KB

Resulting in a lot of comments
image
image1481Ă—925 47.7 KB

Other PRs for those repositories didn’t have this issue.
EDIT: today we had other PRs with the same issue. It seems to be random.

I could even find the relevant part in the SonarCloud Analyze log:
PR with Issue:

INFO: Base dir: /

PR with no issue:

INFO: Base dir: /azp/_work/1/s

The PR build with issue also has the following warning

WARN: SCM provider autodetection failed. Please use "sonar.scm.provider" to define SCM of your project, or disable the SCM Sensor in the project settings.

which makes sense, as the base path is already not correct, so it can find the correct source folder.

The PR build without the issue therefore has some of log statements, that are not in the log for the PR build with the issue like:

INFO: 7 files ignored because of scm ignore settings
...
INFO: SCM collecting changed files in the branch
INFO: SCM collecting changed files in the branch (done) | time=148ms

which again makes sense and therefore resulting into the issue described above.

Either this is dependent on the build agent (don’t think so), or this is an issue in Sonar.

Any ideas?

2

Hi,

There seems to be a lot going on here. I think you’ve correctly identified with problem with the base directory identification and how that impacts SCM data collection and thus leads to old issues showing up in PRs.

So then I loop back to the beginning of your post, where you list (thank you) a project-specific pipeline(?) and then seem to indicate that you’re having the problem with multiple repositories.

So… I think we need to narrow this down.

You see this

  • Only Azure Function repos (Is Azure Function a project type?)
  • Intermittently? Or is it reliable for certain projects? Certain projects when they land on certain build agents?
  • Is the pipeline snippet you presented representative across all relevant projects?
  • What happens before analysis? Is there any cding?

To answer your question, I don’t think this is on the analysis side. The SonarScanner is just acting on the data it’s been given.

 
Ann

3

Hey @ganncamp !

Thanks for the response!
Yes you are right, there is a lot of going on… unfortunately, it is quite hard to break it out from our complex system.

To answer your questions:

  • Only Azure Function repos (Is Azure Function a project type?)
    • We have different kind of repos, mostly of them are either “services” (e. g. normal ASP.NET Core Web APIs) or “functions” (We used the default template for those). They use the normal Snippet Microsoft.NET.Sdk, but the have some special properties and Visual Studio has a dedicated icon for them. So far, we experienced this issue only in repositories that we consider functions.
  • Intermittently? Or is it reliable for certain projects? Certain projects when they land on certain build agents?
    • So far, it seems to be random. Sometimes it happens, sometimes it doesn’t. I already thought about the build agents too, they are however scaled jobs that run on our k8s cluster and they use all the same base image. Afaik, they are single use jobs.
  • Is the pipeline snippet you presented representative across all relevant projects?
    • yes, however the build steps vary between service and functions (we use templates)
  • What happens before analysis? Is there any cding?
    • this is a good hint, I’ll check. While it is a possibility, I’m still puzzled, why sometimes it works and sometimes it doesn’t. If it would be any cding, it should happen all the time.

Can you maybe tell me how the SonarCloudAnalyze gets the Base dir? Is there any way to force the value?

4

Hi,

sonar.projectBaseDir defaults to the directory analysis is triggered from, but may be defaulted from the build for Maven, Gradle, and .NET.

I can also be explicitly overridden, which is not usually a good idea, but maybe what you need to do here.

 
Ann

5

Hi again,

I’ve just learned of this issue, which is probably what you’re facing:

The listed workaround is to explicitly supply the correct base directory, so let me upgrade this:

to “definitely what you need to do here.”

 
Ann

6

Hey @ganncamp !

Thanks for the response and the follow up!

We just rolled out the following fix in a view of our repositories and will continue to monitor, if this issue still persists.

  sonarExtraProperties: |
    sonar.projectBaseDir=$(Build.SourcesDirectory)

Would however of course be nice, if it would get fixed in the sonar scanner.

1 Like