Issue with CLI Scanner and v6 of Azure DevOps Tasks

SonarQube Server / Community Build
1

Hi Colin,

thanks for investigating. Unfortuately we seem to have another issue, this time with an Linux agent and the CLI mode. While the correct scanner is downloaded in the prepare step, it tries to use the wrong scanner in the Run Code Analyze step

The prepare step is configured like this

 task: SonarQubePrepare@6
    displayName: "Sonar Prepare for PR."
    condition: eq(variables['Build.Reason'], 'PullRequest')
    inputs:
      SonarQube: "<serverEndpoint>"
      scannerMode: "CLI"
      configMode: "manual"
      cliProjectKey: "<projectKey>"
      cliSources: $(Build.SourcesDirectory)/terraform/vms
      extraProperties: |
        sonar.pullrequest.key=$(System.PullRequest.PullRequestId)
        sonar.pullrequest.branch=$(System.PullRequest.targetBranchName)
        sonar.pullrequest.base=$(System.PullRequest.SourceBranch)
        sonar.dependencyCheck.htmlReportPath=$(Agent.TempDirectory)/dependency-check-report.html
        sonar.dependencyCheck.jsonReportPath=$(Agent.TempDirectory)/dependency-check-report.json

and does download the CLI scanner …

grafik
grafik1125×561 24.3 KB

… but it tries to use the scanner without CLI in the name

grafik
grafik1179×395 17.9 KB

Can you please investigate as well. Thanks.

1 Like
2

I did notice the same here. In addition, I found the following while digging further down the logs
##[debug]Downloaded: https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-5.0.1.3006.zip file to /agent/_work/_temp/9d5e9c3d-3858-4cd7-83f0-0ed0ab2e2f76
##[debug]Extracting /agent/_work/_temp/9d5e9c3d-3858-4cd7-83f0-0ed0ab2e2f76
Extracting archive
##[debug]Agent.Version=3.240.1
##[debug]Agent.TempDirectory=/agent/_work/_temp
##[debug]testing directory ‘/agent/_work/_temp/1ae07c22-973b-4e5e-9a76-7fce56ba375a’
##[debug]testing directory ‘/agent/_work/_temp’
##[debug]mkdir ‘/agent/_work/_temp/1ae07c22-973b-4e5e-9a76-7fce56ba375a’
##[debug]which ‘unzip’
##[debug]not found
##[warning]Can’t find loc string for key: LIB_WhichNotFound_Linux
##[debug]Processed: ##vso[task.issue type=warning;]Can’t find loc string for key: LIB_WhichNotFound_Linux
##[debug]task result: Failed
##[error]LIB_WhichNotFound_Linux unzip

Appreciate your support in advance.

5

Hey @tegidi and @LuisMauricio

Are these failures on self-hosted agents? What OS?

Using just ubuntu-latest on Azure DevOps Services, I can’t reproduce this issue.

6

@Colin Hey Collin,
yes, it´s self-hosted. Ubuntu 22.04.4 - Linux. In short, we´ve replaced the “v5” by “v6” and set cliVersion parameter to either ‘5.0.1.3006’ or ‘6.0.0.4432’ for testing purpose. Both of them reported the same response above. Do you have any clue, please? Thanks!

7

Yes, self-hosted agents running Ubuntu 22.04.4 as well in our case.

8

@Colin Hey Colin,
All clear. It sounds like “unzip” is mandatory. does it sound right?
We´ve installed it and @v6 tasks worked just fine.
Thanks for your time!

9

Hey there.

We use a Microsoft tool library for Azure DevOps tasks that uses unzip… and I’m surprised they wouldn’t account for say, unzip not being installed by default on Ubuntu.

Is that the case? Or, for some reason, was it explicitly uninstalled in your environment?

1 Like
10

Hi Colin,
unfortunately this doesn’t seem to be the problem in our case. In my screenshot above the prepare step shows that it is extracting the archive with the expected scanner in the prepare step. However it tries to use the wrong scanner (without cli in the name) for some reason.

11

@tegidi It’s quite normal that the unpacked scanner doesn’t have cli in the folder name. What I find more suspicious is that the temp directory in your first screenshot cde... doesn’t match the 2nd screenshot 173....

It would be useful if you could provide your full Azure DevOps Pipeline YML, as well as full build logs from said pipeline (not screenshots)

12

Hi @Colin,

thanks for the hint, I found our issue. It appears we have a task that removed the working directory in order to have a clean Code coverage result. Since the scanner is downloaded in the Sonar task since version 6 it was removed with the working directory and thus was not found later on. We will adapt the pipeline accordingly.

I ran in yet another problem where our OWASP dependency check tried to upload files from the scanner for some reason but was able to resolve it by setting the report directory to a sub directory.

Thanks a lot for your help. This thread and the one it was split from can be closed. (I will comment there too).

1 Like
13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.