Project base path detection is wrong for Azure Functions projects

[andrei-epure-sonarsource]

This is a spin-off from #1294

During the build of Azure Functions projects, a temporary project is generated by ExtensionsCsprojGenerator outside of the project directory and this leads to the wrong computation of the project base path.

Example on Azure Pipelines (azure-pipelines-1.yml ; AZP logs - retained ; SonarCloud report) ,

Actual behavior

The WorkerExtensions.csproj is created in the temp folder (on UNIX, /tmp/y3t0yxhk.0fg/WorkerExtensions.csproj). This leads to

INFO: Project key: 2022-08-05-ReproAzureFunctions INFO: Base dir: / INFO: Working dir: /home/vsts/work/1/.sonarqube/out/.sonar

See screenshot with the skewed project paths:

Expected behavior

The scanner should detect such anomalies and ignore them from analysis.

The path in the above screenshot should be ReproAzureFunctions/Function1.cs.

Work around

Manually specify the base path at the BEGIN step /d:sonar.projectBaseDi=...

Additional information

See the following comments:

• problems that might appear when fixing this issue
• details about ExtensionsCsprojGenerator

[tom-howlett-sonarsource]

If this is hard to resolve, I think it would be acceptable to stop analysis with a warning that asks the user to set a projectBaseDir when it can't be resolved correctly.

[andrei-epure-sonarsource]

@tom-howlett-sonarsource that would happen for all Azure Functions projects outside of Azure Pipelines. Indeed, if the warning and instructions are clear, it should be fine, I guess.

[simonvandermeer]

We have also been running into this problem. Only we can't seem to fix it by setting sonar.projectBaseDir. The most notable difference between out situation and the repro is that we're analysing a solution and not a single project. I'll add the relevant Azure DevOps YAML pipeline code below.

I have been trying for a while to find a workaround but haven't succeeded yet. The pipeline also fails hard due to our warnings as errors policy. I would exclude this specific warning from treating it as an error (with /p:NoWarn) but can't due to it not having a code to exclude.

- task: SonarCloudPrepare@1
  displayName: Prepare analysis on SonarCloud
  inputs:
    SonarCloud: SonarCloud
    organization: ${{ parameters.sonarCloudOrg }}
    scannerMode: MSBuild
    projectKey: ${{ parameters.sonarCloudProjectKey }}
    projectName: ${{ parameters.sonarCloudProjectName }}
    extraProperties: |
      sonar.scanner.metadataFilePath=$(Agent.TempDirectory)/sonar/$(Build.BuildNumber)/test/report-task.txt
      sonar.exclusions=**/Migrations/*.cs
      sonar.projectBaseDir=src

- task: DotNetCoreCLI@2
  displayName: DotNet restore
  inputs:
    command: restore
    projects: ${{ parameters.solutionPath }}
    feedsToUse: config
    nugetConfigPath: ${{ parameters.nugetConfigPath }}

- task: DotNetCoreCLI@2
  displayName: DotNet build
  inputs:
    command: build
    projects: ${{ parameters.solutionPath }}
    arguments: --configuration ${{ parameters.buildConfiguration }} --no-restore /p:TreatWarningsAsErrors=true /WarnAsError

- task: DotNetCoreCLI@2
  displayName: Run tests
  inputs:
    command: test
    projects: ${{ parameters.solutionPath }}
    arguments: --configuration ${{ parameters.buildConfiguration }} --no-build --collect "Code Coverage" --settings src/.runsettings

- task: SonarCloudAnalyze@1
  displayName: Run code analysis

- task: SonarCloudPublish@1
  displayName: Publish quality gate result

[andrei-epure-sonarsource]

Hi @simonvandermeer - please open a topic on https://community.sonarsource.com where we can help clarify what is the root cause of your problem, and open a new issue in the correct repository (this one or maybe some other repository) if necessary or even help you get unblocked.

We only use github to keep track of issues that are triaged and confirmed.

Thanks!

[cheesi]

This issue just haunted us for months. We implemented the workaround now, and hope it works.

Would be really nice, if this issue would get fixed.

[andrei-epure-sonarsource]

Sorry, we should get back to this.

@denis-troller , back in the day Tom suggested:

I think it would be acceptable to stop analysis with a warning that asks the user to set a projectBaseDir when it can't be resolved correctly.

I think we should prioritize this in the next hardening sprint for S4NET.