SonarCloud Gate : Not Computed Status

Template for a good new topic, formatted with Markdown:

  • ALM used: Azure DevOps

  • CI system used: Azure DevOps

  • Scanner command used when applicable: Using task SonarCLoud Prepare (Cli Mode)

  • Languages of the repository: Angular

  • Error observed:

    • Apparently on October 1st, our SonarCloud organization was upgrade. The new version allowsto customize what SonarCloud understands as “New Code”

    • Our Gate Rules are based on Overall Code and New Code.

    • After this date, gates for our long term branches started to show status Not Computed. When entering the project screen, we had to manually configure the new code for the project and rescan so that the gate would be computed as passed or failed.

    • We changed the global Organization configuration for new code to use the same default previously used: New code = code changed in last 30 days.

    • Even after doing that, whenever we create a new long term branch, the “new code” inside the project is correctly configured, but the first scan always get status Not Computed. The message we see is The gate will be computed in next scan.

  • Steps to reproduce

    • Configure Organization New Code as last 30 days

    • In the default gate, configure rules based on overall code and new code

    • Create a new branch in your repo, following the rules for long term branches

    • analyse the project using azure devops

    • First analysis for the branch will generate gate status: Not Computed

How do I get SonarCloud to compute the gate on the first scan, as it used to do before October first?

Hello @Jane, we are investigating your issue and i will keep you updated here when we have something available.

Hi @Jane. This behavior is due to our new feature, where we make the quality gate not available at the first analysis. Please have a look into our Community announcement and don’t hesitate to reach us if necessary!

1 Like

I understand that the Gate satus is not generated for new projects. But Is it supposed to be not computed for preexisting projects with “New Code” already configured when creating new long-term branches?

Hi @Jane. The Quality Gate focus is on new code, so we can’t generate it in a first analysis for a long living branch, since there is no “previous code” to compare. The new code configuration applies for the second and further analysis on those branches, generating (or not) the Quality Gate.

This change is creating many problems for existing pipelines. I did not identify in the documentation any parameter similar to “sonar.leak.period” for the “Previous version” option that solves the “none” or “not computed” status problem for existing projects.

Hello @andressantos10, could you please describe your scenario a bit? SonarCloud still generate the Quality Gate for Pull Requests at first analysis, only the long living branches were improved, since the gate is focused on new code (for PRs new code is what was changed related to the target branch but for long living branches there is no target, so we use the new code configuration to determine it).

Hi @Alexandre_Holzhey my scenario is: We have many projects and the codes are analyzed in build process and not in Pull Resquest. We have code with + of 30 days or new code with period inferior 30 days.
In pipeline, we have branchs develop for enviroment dev and branch release for enviroments qa, homol and production. All branchs are analyzed in build process by sonar and in first analysis the pipeline is reported as “None” in Azure DevOps(in extension) and “Not Computed” in sonarcloud dashboard. This change has generate many impacts in my enviroment, my gate is configured in post-deployment in release step pipeline and with status none, it-s fails.

Do you understand me?


Hi @andressantos10. Yes, that is clear, thanks!

SonarCloud will not generate the Quality Gate for long living branches after the latest new code features were released. This is the expected behavior, since these branches are supposed to be gradually incremented by adding short living branches. Also, does not make sense to generate it because we don’t have new code to compare.

SonarCloud still generate the quality gate for short living branches, like the pull requests. But could be any short living branch, depends on the configuration you have for the project branches. See the image below from a local test i did:


The release-1.0 branch don’t have a Quality Gate because was the first analysis. It is not possible to compare it since there are no previous version on that branch (long living one). If i merge the short living branch test1 into it, then we will get the Quality Gate, because we are going to have a new code on top of the previous one (also depending on the new code configuration, but let’s suppose here i am using previous code config).

Based on what you said, i guess that only the branches develop have the Quality Gate missing, right? To me, the release, homol and production ones should be long living ones and have the Quality Gate. Could you please confirm my understanding? Also, could you check the branches configuration and tell me what you have (naming pattern expression)? To me, looks like your develop branches miss the QG because they match the pattern for long living branches.

HI, @Alexandre_Holzhey This change about branchs long-lived, I understand and has impacted my projects configurations, I used regex to set this config, for example:

Set Long living branches pattern

Write-Host “”
Write-Host “Set Long living branches pattern”
$BranchPattern = “(master|develop).*”
$LongLivingBranchesPatternPost = $SetKeyURL -f $BuildRepositoryNameURL, “sonar.branch.longLivedBranches.regex”, $BranchPattern

Try {
$Post = Invoke-RestMethod -Method Post -Uri $LongLivingBranchesPatternPost -Headers $Headers
Write-Host " sonar.branch.longLivedBranches.regex: “$BranchPattern” done!"
} catch { Write-Host " sonar.branch.longLivedBranches.regex: “$BranchPattern” failed!" }

Ok, I remove release branch in regex, in my script sonar setup to my projects. To test, I did delete project in sonar portal, and execute my pipeline. Regex long-lived branch is: "Long living branches pattern: (master|develop)."*.

My branch develop are coverage with 51,7%, I created a feature(short-lived) branch named “merge-sonar” based on branch develop(long-lived). After I realize a merged to my branch “releaseandre-v1”(short-lived) and my coverage is equal 0.

Your understanding is correctly but my branch named “release-v*” is used for environment qa, homolog and production.

I continue with “problems” because in the test changing the branch of “release-v *” for short life the coverage is below that defined in the quality gate. Do we have an alternative?

I found this change very drastic and with no time to prepare. My development team is not yet prepared for such changes.