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?
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
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)?
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.
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.
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.
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.