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?
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!
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.
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
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.
About the short living branch coverage: it is based on the new code introduced on that branch. For long living branch this is different: we use the new code definition to deduce what is effectively new code. I think you got zero coverage on the testing short living branch you have created because the new code was missing code coverage (tests), am i correct?
To clear things a bit: you need to keep having QualityGates for first analysis in “release-v” branches, right? How are you using those release branches (give us a example flow)?
@Alexandre_Holzhey, yes! We need firt-analysis for “release-v” branches. However I have doubts if we will be effective.
My flow, with details:
Concept branch:
Branchs develop, master and release-v* are considered long living.
Branchs feature-v* and hotfix are considered short living.
Step 1: My dev team create a branch feature(short living), after create a PR to merge branch develop. In moment the merge the build pipeline is executed and run code analisys sonar is make. After release pipeline create my application in enviroment develop in my cloud.
Step 2: If ok deployed in enviroment develop, my dev team create a branch release based on branch develop (already analyzed). The build pipeline are executed in branch release-v*.(In my vision in that model, the coverage will fail, why branch release is based in branch develop, no changes). After release pipeline executed deploy in enviroments QA, Homol (in homol we have the gate SonarCloud in post-deployment) and PRD.
Step 3: If ok deployed in all stages, is realized o merge to branch master. (just for your knowledge of my total flow)
Additional informations:
We have a script to is executed in firt step build pipelines named “SetupSonar.ps1”, this script create project, add permissions to users, getting tokens in Keyvaults Azure, authenticate in SonarCloud, Set PR integration and set new code period to 30 days, Set Long living branches pattern, after change general in format of analisys in code, my issues starting.
I tried to describe my complete flow in many details to make it easier for you to understand and see how you can help, as I am not seeing any way out of this case.
Hi @andressantos10. The Quality Gate can have rules based on 2 conditions: new code and/or overall code. The default one uses new code conditions. When configuring it only with rules based on overall code, i get a quality gate on every analysis, including the first ones. But, the quality gate can be configured for the project only, so this is not an option to you i guess. Maybe you can try to configure a quality gate with both overall and new code conditions and see how it works for your scenario.
Besides that, the new code condition will not render a quality gate, since there is no new code as required by this condition.
As mentioned before we updated the new code feature. Are you also missing the quality gate on long living branch analysis? Have you looked the previous messages in this topic and found something that could help?
Hi @Alexandre_Holzhey, I already used the overall code model in my scenario, the problem is that I have no options. Since I have to define “new code” at the organizational level, any changes I make will not have the expected effect.
Ideally, SonarSource would rollback the change or allow me to use the tool as it was before this change without notice.
Unfortunately, I understand that I am only one of thousands of customers, but I will consider adopting another tool, as I am not seeing any solution.
First of all thank you for providing detailed descriptions of your workflow .
If I understood correctly, you are creating release branches (long-living) from your develop branch and do not make any changes to them. Then, they undergo a QA process and are later merged with master / published to production. Before the merge / publication, you are checking the Quality Gate status of the release branch.
If my understanding is correct, then conditions on new code in the quality gate are not going to work for your workflow since there is no new code on your release branches (it was just created from develop and no code changes were done). Removing conditions on new code from your Quality Gate will make it available even for the first analysis and should make your workflow work.
Hi @Alexandre_Holzhey, I already used the overall code model in my scenario, the problem is that I have no options.
Could you give us more information on the conditions in your Quality Gate (e.g. a screenshot of the configuration)? I think that could help us better understand what went wrong.
Hello @Martin_Bednorz, same case that @andressantos10 here. My long living branches correspond to releases have “no computed status” as they are analyzed only once, just when the master branch is tagged.
Is there any way to remove “new code” conditions only for long living branches, so they could be analyzed only once?
I have the same use case where release branch are used in build pipelines and it is showing as Not computed because of the same reason which is discussed in this topic. Is there any solution for it?
Is it possible to always compare first scan with master branch?
.