Setting sonar.projectBaseDir works differently in SonarCloudPrepare@3 than in SonarCloudPrepare@2

SonarQube Cloud
, , ,
1

Similar issue to https://community.sonarsource.com/t/sonarcloudprepare-3-0-3-no-longer-respects-sonar-projectbasedir/129656

Except with scannerMode: ‘CLI’

  - task: SonarCloudPrepare@3
    displayName: 'SonarScan Prepare cli analysis configuration'
    inputs:
      SonarCloud: 'SonarCloud'
      organization: '<myorgid>'
      scannerMode: 'CLI'
      configMode: 'manual'
      projectKey: '${{ parameters.sonarProjectKey }}'
      projectVersion: '${{ parameters.buildNumber }}'
      cliProjectKey: '${{ parameters.sonarProjectKey }}'
      cliSources: '${{ parameters.sonarSources }}'
      extraProperties: |
        sonar.verbose=true
        sonar.projectBaseDir=${{parameters.sonarProjectBaseDir}}

# Build and test npm app

- task: SonarCloudAnalyze@3 # Here it breaks

Where parameters.sonarProjectBaseDir is E:\agent_work\7\s\ProjectName
and parameters.sonarSources is src\react\React.Web

Builds ends in an error.

14:34:51.115 ERROR Invalid value of sonar.sources for <projectkey>
##[error]14:34:51.139 ERROR The folder 'E:\agent\_work\7\s\src\react\React.Web' does not exist for '<projectkey>' (base directory = E:\agent\_work\7\s\ProjectName)
java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.scan.ProjectLock
	at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:52)
	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:678)
  ...
Caused by: org.sonar.api.utils.MessageException: The folder 'E:\agent\_work\7\s\src\react\React.Web' does not exist for '<projectkey>' (base directory = E:\agent\_work\7\s\ProjectName)

Scanner should scan in E:\agent_work\7\s\ProjectName\src\react\React.Web, but it is trying to scan folder E:\agent_work\7\s\src\react\React.Web.
It clearly has the correct base directory E:\agent_work\7\s\ProjectName.

This has worked with SonarCloudPrepare@2 version with the following configuration

  - task: SonarCloudPrepare@2
    displayName: 'SonarScan Prepare cli analysis configuration'
    inputs:
      SonarCloud: 'SonarCloud'
      organization: '<myorgid>'
      scannerMode: 'CLI'
      configMode: 'manual'
      projectKey: '${{ parameters.sonarProjectKey }}'
      projectVersion: '${{ parameters.buildNumber }}'
      cliProjectKey: '${{ parameters.sonarProjectKey }}'
      extraProperties: |
        sonar.verbose=true
        sonar.projectBaseDir=${{ parameters.sonarProjectBaseDir }}
        sonar.sources=${{ parameters.sonarSources }}
4

Hello @simo-esko ,

In order for me to ensure I’m validating correctly the extension and try to reproduce a similar environment than yours, can you please send me your debug logs?

You can enable system diagnostics when you are running the pipeline
image

or add a variable system.debug: true to your pipeline definition.

Thank you for your help

5

Thank you for the message.

We are using a setup where pipeline checkouts two different repositories under the build agents source folder (E:\agent_work\7\s). First one is our templates repo that contains all centrally maintained azure pipeline templates. Second is the actual source code repo that we want to analyze.

We have about 40 of those source repos and most of them have their SonarCloud issues analyzed and reviewed thru version 2 of SonarCloud devops tasks. The root of the analysis is something like E:\agent_work\7\s\reponame for all pipelines so changes in the paths are difficult since all issues will be reported as new issues if the paths don’t match after version 3 upgrade.

I ran the pipeline system.debug on.

There is the log for the SonarCloudAnalyze@3
470ce5ad-1256-4578-9854-30e6580d6958__apis_build_builds_80943_logs_27.log (22.5 KB)

For the SonarCloudPrepare@3 the task does not log much
470ce5ad-1256-4578-9854-30e6580d6958__apis_build_builds_80943_logs_13.log (1.0 KB)

1 Like
6

Hello @simo-esko ,

After some investigation and thanks to your logs, I could notice that Azure DevOps automatically converts the value of cliSources to an absolute path relative to the root folder (instead of forwarding the value as-is to the Scanner CLI), because we mark it in our task configuration as being a path.

So when you set src\react\React.Web in cliSources, what our task sees is E:\agent_work\7\s\src/react/React.Web.

You have multiple workarounds to this:

  • Do not set cliSources and instead define sonar.sources in the extraProperties as a relative path
  • Set cliSources as an absolute path already (so, starting from your sonarProjectBaseDir).

I’ve created a ticket SONARAZDO-440 which you can track to follow our progress on this, as we will likely want to workaround this Azure behavior.

1 Like