SonarCloud Gate : Not Computed Status

I changed my tasks to run a second SonarCloud Analysis when the gate is not computed.

Here you have the powershell script that creates the SonarGateComputed environmentvariable that enables or disables the second SonarCloud task:


#=======================================

#

# this scripts sets an environment variable in Azure Devops if the SonarCloud Gate Result is not computed

$SonarToken="PUT YOUR TOKEN HERE"

Write-Host "Build Reason $Env:BUILD_REASON"

if ($Env:BUILD_REASON -eq "PullRequest")    # Pull Request aplies only New Code Rules and allways works

{

  Write-host "SonarCloudGateComputed: true"

  Write-Host "##vso[task.setvariable variable=SonarCloudGateComputed]true"

}

$Repo= $Env:BUILD_REPOSITORY_NAME

$MyBranch=$Env:BUILD_SOURCEBRANCH.Replace("refs/heads/","")

$Request="https://sonarcloud.io/api/qualitygates/project_status?projectKey=$Repo&branch=$MyBranch"

Write-Host "Request: $Request"

$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"

$headers.Add("Authorization", "Basic $SonarToken")

$headers.Add("Content-Type", "application/json")

$response = Invoke-RestMethod $Request -Method 'GET' -Headers $headers -Body $body

if (!$response.projectStatus.status)

{

   Write-Host "##vso[task.logissue type=error]Error retrieving gate status"

   Write-Host "##vso[task.complete result=Failed]"

   exit

}

else

{

  $StatusSonar = $response.projectStatus.status

  write-Host "SonarGate Result: $StatusSonar"

  if($StatusSonar -eq "NONE")

  {

     Write-host "SonarCloudGateComputed: false"

     Write-Host "##vso[task.setvariable variable=SonarCloudGateComputed]false"

  }

  else

  {

     Write-host "SonarCloudGateComputed: true"

     Write-Host "##vso[task.setvariable variable=SonarCloudGateComputed]true"

  }

}

Here you have the bash script that does the same:


#!/bin/bash

SonarToken="YOUR TOKEN HERE"

echo "Build Reason: $BUILD_REASON"  # Analysis based on pull request only validate rules on new code and allways work

if [ "$BUILD_REASON" = "PullRequest" ]; then

   echo "SonarCloudGateComputed: true"

   echo "##vso[task.setvariable variable=SonarCloudGateComputed]true"

   exit

fi

Repo="$BUILD_REPOSITORY_NAME"

MyBranch=${BUILD_SOURCEBRANCH#"refs/heads/"}

echo "curl -u \"$SonarToken:\" --request  GET \"https://sonarcloud.io/api/qualitygates/project_status?projectKey=$Repo&branch=$MyBranch\" 2>logcurl.txt"

JsonSonar=$(curl -u "$SonarToken:" --request  GET "https://sonarcloud.io/api/qualitygates/project_status?projectKey=$Repo&branch=$MyBranch" 2>logcurl.txt)

echo "$JsonSonar" | jq '.' 2>jqlog.txt

StatusSonar=$(echo "$JsonSonar" | jq '.projectStatus.status' 2>jqlog.txt)

echo "SonarGateResult: $StatusSonar"

if [ -z "$StatusSonar" ] || [ "$StatusSonar" = "null" ]; then

   echo "##vso[task.logissue type=error]Nao foi possivelError recovering SonarGate Status"

   echo "##vso[task.complete result=Failed]"

   exit

elif [ "$StatusSonar" = "\"NONE\"" ]; then

   echo "SonarCloudGateComputed: false"

   echo "##vso[task.setvariable variable=SonarCloudGateComputed]false"

else

   echo "SonarCloudGateComputed: true"

   echo "##vso[task.setvariable variable=SonarCloudGateComputed]true"

fi

This is how the tasks look like in Azure Devops:


steps:

  - task: SonarSource.sonarcloud.ce096e50-6155-4de8-8800-4221aaeed4a1.SonarCloudAnalyze@1

    displayName: 'Run Code Analysis'

  - task: AzureCLI@2

    displayName: 'Checa GateSonar-Linux'

    inputs:

      azureSubscription: '$(AzureSubscriptionDefault)'

      scriptType: bash

      scriptPath: '$(TemplatesRepo)/scripts/checa-sonar-gate.sh'

      failOnStandardError: true

    condition: |

      and (succeeded(),

           or (eq( variables['Agent.OS'], 'Linux' ),

               eq( variables['Agent.OS'], 'Darwin' )

              )

          )

  - task: AzurePowerShell@4

    displayName: 'Checa Gate Sonar - Windows'

    inputs:

      azureSubscription: $(AzureSubscriptionDefault)

      ScriptPath: '$(ScriptsRepo)/Scripts/checa-sonar-gate.ps1'

      FailOnStandardError: true

      azurePowerShellVersion: LatestVersion

    condition: and (succeeded(), eq( variables['Agent.OS'], 'Windows_NT' ))

  - task: SonarSource.sonarcloud.ce096e50-6155-4de8-8800-4221aaeed4a1.SonarCloudAnalyze@1

    displayName: 'Run Code Analysis 2'

    condition: |

       and(succeeded(),

           eq(variables['SonarCloudGateComputed'], 'false'))

           )

Hello @javier.brea and @varunverma,

Do I understand correctly that you create a release branch (that is setup as a long-living one in SonarCloud) where no changes in the code are being made?

@javier.brea you mentioned that your release branch is created from master, correct? In that case, would it be possible in your workflow to check the Quality Gate of the master branch if it is safe to release?

@varunverma it is possible to compare to master if you set the release branch as a short-living one. Then, it will focus only on the new code in that branch compared to your master branch. The down-side of this approach is that only the issue-focused, hard-coded quality gate is available on a short-lived branch. In addition to that, from which branch are you creating the release branch? If it is something like development, would it be possible to use that Quality Gate to determine whether it is safe to release or not?

Best,
Martin

Hi @Martin_Bednorz,

I will try to explain as best as I can.

The release branch is created from previous sprint release branch. For e.g. for Sprint 77, release branch will be created from Sprint 76 release branch at the start of sprint 77(end of 76 sprint) and release-76 branch will be merged to master at the end of Sprint 76.

But when we do first build on release-77 branch it will have some changes on top of release-76 branch and that is when we are doing sonarcloud analysis using sonarcloud app from Azure pipelines.

So the first time, as it is a long live branch, it is marked as Not Computed even though it is having new code compare to master branch or previous release branch. We can’t make the release branch as short lived.

Hi @Martin_Bednorz, my “release” branches are tags from the master branch, because my workflow publishes the packages when I create tags for each new package version. So the quality was already checked in the master branch, you’re right. I have the version tags configured as long living branches in SonarCloud in order to have a historic of the quality of every releases, but it is not a really important requirement, so I could configure them as short-living branches.
Thank you anyway :slightly_smiling_face:

1 Like

Hi @varunverma,

Thank you for the explanation, that makes it clear.

The difficulty is that even though there is new code on the branch, our comparison needs an analysis on SonarCloud to compare it to, so for SonarCloud there is no new code on the first analysis. We are going to look into improvements for this in the near future.

If I understood correctly, your build on Azure pipelines fails because the quality gate was not computed. Would it help your use-case if the build would not break because of a not computed quality gate (since this is expected for the first analysis of all long-living branches right now)?

Best,
Martin

@Martin_Bednorz @Alexandre_Holzhey, is it possible for sonarsource to rollback this change? Or give us the option of the old model?

This change is impacting many people and companies, because some scenarios were not thought of in this change.

1 Like

Hello @andressantos10,

The behavior before we rolled out the changes was the same in essence, the first analysis of long-living branches did always pass if you were using the default quality gate (it has conditions on new code only and there is no new code for the first analysis). This fact is now much clearer with the changes we rolled out.

To better understand your workflow and find a solution that works for you, could you please clarify the following points:

  • Could you sent me the conditions you have selected in your quality gate? If you are not comfortable with that in public I am happy to connect via a private message.
  • Are you checking the status of the quality gate of your release branches with a custom tool (e.g. via our API) or with a tool directly provided by us?
  • Are there any changes made on the release branches? If not, would it be possible to use the quality gate status of your development branch at the point you create the release branch? If there are no changes, then moving the quality gate check in front of creating the release branch could be one possible solution.

Best,
Martin

Hi @Martin_Bednorz,

In past posts I shared my branche flow to easy the understand that impacts in my pipelines.

I understood that it is only for new code, but you did not understand that the essence was broken. I say this, because I need to run an analysis 2 times to get a status from my code, and the metrics were not so assertive in my opinion. We have several people with the same “problem” after this change.

  • See bellow, my quality gate conditions:

  • We use tools provided by you. The gate qulity is check with “Check SonarCloud Quality Gate Status” in post-deployment in Azure DevOps.

  • Branches releases have changes in many cases, as they may need corrections, improvements, etc. during the development process.

Bests

Hi team Sonar, do you have any update?

Hello @andressantos10,

Thank you for sending more details around your workflow.

We are currently discussing a few small improvements around long-living branches and quality gates that are going to simplify that kind of workflow. Once I have more details I am going to share them in this thread.

Best,
Martin

Did you have any update for this problem?

Any update regarding this?

We have a scenario where we use long lived release branches, which is kept for traceability, this release branch is built once.
Today we get the “Not computed” message but we really would like the red/green light from the Quality gate
which shows up so nice in the build in Azure Devops as well.

Unfortunately there is no update yet. We have a few things in mind to improve the situation, and you can follow the following card to receive updates / provide feedback: Fine-tune behavior around Quality Gates and new code availability - SonarCloud | Product Roadmap .

Hi @Martin_Bednorz please, priorize this demand we’re 7 months waiting a solution.

Regards

after this change, it broke its build flow and is impacting the client’s business
Is there a forecast for the correction?

1 Like