Not sure what is up with your extension but it does not work that well in Azure DevOPS

[nicholas.clark]

I have been tailing both NGNIX logs and SonarQube. The behavior I am seeing is one moment it connects and works the next pipeline run it either works or fails. I can not get to work with any kind of constancy. My SonarQube Developer VM is in Azure Portal. I have added a rule to allow the traffic through from a service tag of AzureCloud which should let the traffic through. Durring the SonarQube prepare step sometimes it can get to api/version sometimes not. Mostly it can not get there and the pipeline fails.

This makes it hard to setup a scan for our React Mobile application for iOS and Android since I can not have the pipeline failing ever other try.

I have tried to use a self-hosted agent proxying the connection. That lead to other issue with regards to Python and Java being found on the Mac Mini in our office. We are trying to use the latest Mac OSX agent in Azure DevOPS. I have also tried windows with the same issues.

I have learned that the other groups are not using your sonarQubePrepare@5 extension.* So now am curious about if it is something with that version of this extension.

Other groups are using these PowerShell commands instead.

`$QualityGateResult = Invoke-WebRequest -Uri “https://$(sonarServerName)/api/qualitygates/project_status?projectKey=$(sonarqube_projectkey)” -Method GET -Headers $headers -ErrorAction Stop -Verbose

if ($QualityGateResult.Content.Contains(‘“projectStatus”:{“status”:“OK”’)){
Write-Host (“SonarQube scan passed Quality Gate!!!”) -ForegroundColor Green
}

else
{
throw “Quality gate failed. Please check and fix the issues. Quality gates status can be viewed on SonarQube Server.”
}`

This seems to work all the time. I will be trying this with my YAML pipeline next.

So this call does not try to speak to api/version whereas the extension is the 1st thing it does. This call works sometimes and other times it does not. I have added this rule into the NSG that Sonarqube uses:

This rule lets the service tag of AzureCloud through for connection to the ports in the middle here 443, 8443, 8080, 80, 9090, 9000.

I have also tested this solution by doing a curl in a pipeline:

This gave me a 200 response which is what I would expect for an HTTP response from your API.

Unsure if anyone else has run into this. Also we are on latest SonarQube developer version if this helps which is 10.4

Thanks,
Nick

[Colin]

Hey there.

I would suggest first trying to isolate the issue to the extension or more generally the network connectivity between your agent and SonarQube.

In a pipeline using the extension that often fails, you could try adding a command (curl or Invoke-WebRequest) to <sonarqube_url>/api/server/verison (the same URL the extension is calling) and see if URL request fails as well, or if only the extension fails.

If the URL request also fails (without the extension), we know it’s a network connectivity issue. If it works, but the extension fails to call the same URL, we know it’s an issue with the extension.

[nicholas.clark]

Even this works off and on… CURL works one minute next run it does not work. I have turned verbose on in sonarqube I am not seeing anything is very odd

[Colin]

Well, if you never have trouble hitting it from your browser but the problem only comes when using the build agent, it sounds like there’s a connectivity problem between those two resources.

[nicholas.clark]

So this works fine if I use a classic pipeline and use your extension and use mac latest. However if I use your extension and do the same thing using a YAML pipeline it does not work.

So I am not sure what is up with that. I have a meeting with Microsoft Support later to go over this with an NSG expert. However it is odd it works one way but not the other. I do not want to run this from a YAML file not in source control.

[Joe]

@nicholas.clark

So this works fine if I use a classic pipeline and use your extension and use mac latest. However if I use your extension and do the same thing using a YAML pipeline it does not work.

Can you share screenshots of your classic pipeline and the yaml pipeline so we can see the difference?

[nicholas.clark]

Classic Pipeline example:

There no reason to see the whole YAML pipeline and there are things in it that I can not share but it fails on the SonarQube Prepare step for each of the mobile apps for iOS and Andriod:

      - task: SonarQubePrepare@5
        displayName: 'SonarQube Prepare for iOS'
        inputs:
          SonarQube: 'sonarServer'
          scannerMode: 'CLI'
          configMode: 'manual'
          cliProjectKey: $(sonarQubeiOSToken)
          projectName: $(sonarQubeiOSProjectName)
          cliSources: './keurig-native/apps/keurig-native-app'
          extraProperties: |
            # Additional properties that will be passed to the scanner, 
            # Put one key=value per line, example:
            sonar.exclusions=**/*.tsx
            sonar.inclusions=**/*.ts
            sonar.verbose=true
        continueOnError: true

      - task: SonarQubePrepare@5
        displayName: 'SonarQube Prepare step for Android'
        inputs:
          SonarQube: 'sonarServer'
          scannerMode: 'CLI'
          configMode: 'manual'
          cliProjectKey: $(sonarQubeAndroidToken)
          projectName: $(sonarQubeAndroidProjectName)
          cliSources: './keurig-native/apps/keurig-native-app'
          extraProperties: |
            # Additional properties that will be passed to the scanner, 
            # Put one key=value per line, example:
            sonar.exclusions=**/*.tsx
            sonar.inclusions=**/*.ts
            sonar.verbose=true
        continueOnError: true```

The **Android** app is written in **Gradle** whereas the **iOS** one is using **Xcode**.

I am aware of the fact mac agents are not include in service tags for cloud and have added these CIDRs to the NSG rule manually.  This works fine using classic pipeline but not using the extension and YAML.  I see a bunch of other posts on the forum about this same kind of issue.  However none of them seems to have any solution provided.

[nicholas.clark]

I gave you the information you asked for any updates?

[nicholas.clark]

Be great to get some help on this issue where is this set I am seeing this in the output on the pipeline job:

##[debug]c9f13c99-4206-4cb0-a264-6d495685ad47 auth param apitoken = undefined
##[debug]c9f13c99-4206-4cb0-a264-6d495685ad47 auth param username = ***
##[debug]c9f13c99-4206-4cb0-a264-6d495685ad47 auth param password = undefined

I have gotten further I see you need to set this token in the extra parameters but it not taking the value of the variable I have set I see this now:

##[debug]cliProjectKey=$(sonarQubeiOSToken) ##[debug]cliProjectName=undefined ##[debug]cliProjectVersion=1.0

not sure how this is suppose to look in YAML am trying this now:

  - task: SonarQubePrepare@5
            displayName: 'SonarQube Prepare for iOS'
            inputs:
              SonarQube: 'sonarServer'
              scannerMode: 'CLI'
              configMode: 'manual'
              cliProjectKey: $(sonarQubeiOSToken)
              projectName: $(sonarQubeiOSProjectName)
              cliSources: './keurig-native/apps/keurig-native-app'
              extraProperties: |
                # Additional properties that will be passed to the scanner, 
                # Put one key=value per line, example:
                sonar.exclusions=**/*.tsx
                sonar.inclusions=**/*.ts
                sonar.verbose=true
                'sonar.projectKey=$(sonarQubeiOSToken)'

[nicholas.clark]

I not sure about this forum. Hopefully someone has some ideas for me.

I find a lot of post that have no solutions and just kind of die out.