SonarQubePrepare@7 Azure DevOps Task not reading sonar.projectBaseDir

SonarQube Server / Community Build
1

My versions:

  • SonarQube Version: v10.6 (92116)[ACTIVE]
  • Azure DevOps Task: SonarQubePrepare@7.0.1

I have an Azure DevOps task like this:

      - task: SonarQubePrepare@7
        inputs:
          SonarQube: SonarQube New
          projectKey: LogixStaffing
          projectName: LogixStaffing
          projectVersion: LogixStaffing-Master
          extraProperties: |
            sonar.verbose=true
            sonar.projectBaseDir=C:\_IT\LogixApplications\apps\mvc\LogixStaffing

It generates the output that is contained in the attached “SonarQubePrepare.log” file.

SonarQubeAnalyze.log (267.8 KB)

However, it seems like the “projectBaseDir” config entry is not being read correctly, because the subsequent “SonarQubeAnalyze@7” task fails. See the attached “SonarQubeAnalyze.log” file.

SonarQubePrepare.log (11.4 KB)

Is this the correct format for specifying the “projectBaseDir” option? Why is it not being picked up correctly?

1 Like
2

I add to ticks with the upgrade
'sonar.projectBaseDir='$(Build.SourcesDirectory)/****'

3

Devin_Quince: Some questions about that code:

  1. Why do you have 3 quotes? That looks like a bug, because there is no closing quote.
  2. What do the four asterisks represent? Are they a glob pattern? Where is this documented?
  3. According to the documentation, you are not supposed to add a glob pattern to the project base directory, because it is exactly that: a base directory specification, not an array of files to include.

Furthermore, I tried it out, and it just gives me this error:

##[error]Unhandled Exception:
##[error]System.ArgumentException: Illegal characters in path.

Can you clarify?

4

*** isredacted info. They are ticks and not quotes and not sure why 3 works. Try this.
'sonar.projectBaseDir='$(Build.SourcesDirectory)/foldername'

5

To clarify, the ’ character is called an apostrophe or a single quote. It is not a tick.
I tried adding 3 single quotes, but it makes SonarQube crash with a syntax error, as expected. Thanks anyways, I will wait for another to respond.

6

Hi @jnesta-lh,

This is a bug we discovered yesterday in the way extraProperties are handled in v3 tasks on Windows agents.

This has been fixed in v7.0.2 of the extension.

Denis

2 Likes
7

Dennis,
Thank you. However, even after updating to version 7.0.2, I still experience the same behavior. Can you advise?

In this case, I do not think that “removing backslashes” would be an issue, because then I would expect SonarQube to be throwing an error something along the lines of:

The path you specified in the "projectBaseDir" option does not exist: CFooBar

However, I do not get any errors of this nature.

8

OK, then let me flag that for our engineers to look at.
Thanks for following up.

1 Like
10

Hi @jnesta-lh

Did that pipeline use to work previously?
Would you mind sharing the whole (redacted) pipeline here?

Denis

11

Hi Devin,

Could you please send us the logs again, in verbose mode, after the update to 7.0.2?

13

Costin,

Sure thing.

SonarQubeAnalyze.txt (267.2 KB)
SonarQubePrepare.txt (11.4 KB)

See the attached logs, which are on version 7.0.2.

For context, here is the Azure DevOps pipeline that is invoking it, a file called “dotnetframework_48_build.yml”:

parameters:
  - name: projectName
    type: string
  # The full path to the code directory to check.
  # For example: C:\_IT\LogixHealth\apps\mvc\LogixStaffing
  - name: codeDirectory
    type: string
  - name: projectSolutionName
    displayName: The name of the ".sln" file to compile.
    type: string
  - name: artifactDirectory
    type: string
  - name: artifactName
    type: string
  - name: validate
    displayName: Whether to run SonarQube checks.
    type: boolean

steps:
  - task: NuGetToolInstaller@1
    displayName: Install NuGet
    inputs:
      checkLatest: true
  - task: NuGetCommand@2
    displayName: Install dependencies
    env:
      NODE_EXTRA_CA_CERTS: C:\_IT\BEDROOTCA001.cer
    inputs:
      command: restore
      restoreSolution: ${{ parameters.codeDirectory }}\${{ parameters.projectSolutionName }}
      feedsToUse: select
      vstsFeed: LogixLibrary
  - ${{ if eq(parameters.validate, true) }}:
      - task: SonarQubePrepare@7
        inputs:
          SonarQube: SonarQube New
          projectKey: ${{ parameters.projectName }}
          projectName: ${{ parameters.projectName }}
          projectVersion: ${{ parameters.projectName }}-Master
          extraProperties: |
            sonar.verbose=true
            sonar.projectBaseDir=C:\_IT\LogixApplications\apps\mvc\LogixStaffing
  - task: MSBuild@1
    displayName: Build
    inputs:
      solution: ${{ parameters.codeDirectory }}\${{ parameters.projectSolutionName }}
      msbuildArguments: /p:OutDir="$(Build.ArtifactStagingDirectory)\\" /p:DeployDefaultTarget=WebPublish --warnaserror
  - ${{ if eq(parameters.validate, true) }}:
      - task: SonarQubeAnalyze@7
  - ${{ if eq(parameters.validate, true) }}:
      - task: SonarQubePublish@7
        inputs:
          pollingTimeoutSec: 300
  - task: PublishBuildArtifacts@1
    displayName: Publish build artifacts
    inputs:
      PathtoPublish: $(Build.ArtifactStagingDirectory)/${{ parameters.artifactDirectory }}
      ArtifactName: ${{ parameters.artifactName }}
      publishLocation: Container
1 Like
17

Hi James,

Thanks for attaching the logs. I reproduced it in my test environment and logged an issue. You can follow the progress here: SCAN4NET-152.

Until a fix is provided, as a workaround, you can try to clone the source code in the Azure DevOps default sources directory (Build.SourcesDirectory).

20

Hey there!

Can I ask you to try pinning the version of S4NET to the freshly baked hotfix version, by adding this on your inputs:

dotnetScannerVersion: '9.0.2.104486'

If everything works as expected, we will soon go ahead with embedding this version on the AZDO extension (meaning you will be able to remove the pinning).

21

I use Azure DevOps Server, not Azure DevOps Services, so that won’t be possible right?

22

Hey James,

Sorry for the delay.
There shouldn’t be a difference between AZDO Server and AZDO Services.
Since you are already using the extension, you just need to set the property I mentioned.

23

To be precise, based on your action:

   - task: SonarQubePrepare@7
        inputs:
          dotnetScannerVersion: '9.0.2.104486'  <---HERE
          SonarQube: SonarQube New
          projectKey: LogixStaffing
          projectName: LogixStaffing
          projectVersion: LogixStaffing-Master
          extraProperties: |
            sonar.verbose=true
            sonar.projectBaseDir=C:\_IT\LogixApplications\apps\mvc\LogixStaffing