We are using Gitlab cloud to run our pipelines. We have sonar cloud integrated in the pipelines. The Gitlab stage for Sonarcloud Linting is called Lint
. As you can see in the image below, when I raised the merge request, it ran a pipeline exclusively for the merge request and the Lint
stage passed with no issues. However, once the merge request got approved(without further changes), I simply merged it to master. However, the same code, now failed with quality gate on the pipeline. This is strange. Can someone explain the reason for this behaviour?
We checked the quality gate configuration on SonarCloud and it applies the same rules for all branches (screenshot below):
Hi Akshay,
If I understand correctly, you had a merge request that passed the quality gate and after you merged that MR into the main branch, the main branch failed the QG. Furthermore, your QG is the default Sonar way QG that only applies conditions to new code.
This behavior is certainly possible. The reason is that even though the same QG is used on both the MR and the main branch, and that QG places conditions only on new code, the definition of new code is different between the main branch and the MR:
In the context of the MR, the new code is defined as that code which was changed by the MR.
In the context of the main branch, new code is whatever the prevailing new code period definition is (last 30 days for example).
In general, these two definitions of new code will rarely coincide, so the outcome you describe is not that surprising.
Further to my answer above,
You did not mention whether the main branch was red (failed) before the merge of the MR.
If in fact,
- the main branch was green and
- you merged a green MR into it and
- that resulted in a red main branch,
then you do have a bit of a weird situation. But it is not impossible. Perhaps you can dig into the details of the analyses and see what exact issues cause the change in the main branch from green to red (if, in fact, this is what is happening)
Alright! I beg to differ on your analysis. Just yesterday, I created a new microservice for our product. New folders, new files, everything from scratch. So the “new code” for the MR should be same as “new code” for master branch right? It happened again. It passed the quality gate on MR and when I merged, it has failed the pipeline on master branch (images below).
As you can see, in the first image, it clearly says “Quality Gate Passed” for conveyor service.
The same thing has failed after merge. As mentioned earlier, the rules for both the branches or merge request are same
Ok. So just to confirm. Did you do an analysis on the master branch before the merge and did that analysis pass?
Of course. We have merged many branches on to master. And every time there is a merge, it triggers QG analysis. Moreover, the problem is clear. The same code for which it passed QG earlier, is not getting passed later on.
So for each of these merge events you have three relevant analysis result sets:
main-branch before merge: QG green
merge request before merge: QG green
main branch after merge: QG red
Are you able to see what the differences are between these analyses, in terms of issues/security hotspots/code smells/coverage that may be causing the different QG results?
Hi Akshay,
We took a look at your project from our side and we think we found the problem:
It looks like
- You are performing the scan with the
sonar.qualitygate.wait
property enabled
- You did not initially have a new code period set for your main branch
In such a case the scan will fail with the message “QUALITY GATE STATUS: FAILED”
This behavior is an error on our part because, in reality, the quality gate did not fail, there was just no QG computed because no new code period was set.
We have opened a ticket to track this issue: https://jira.sonarsource.com/browse/SCCOMM-47
The workaround is to always set a new code period before performing any analyses.
The reason that the quality gate on the MR is green is because for MRs the new code definition is implicitly set as “all code that was introduced with this MR”. In contrast, for the main branch, the new code definition is one of the options like “since last version” or “in last 30 days” etc.
1 Like
I am also facing similar kind of issue. Did you got any resolution on this?
I am trying to merge newly integrated sonar into the master branch but it is failing after raising the MR. Below are my observations
Case :
main-branch : not integrated sonar
dev-branch: added integration for sonar - QG green
dev - master: raised MR for master branch - QG red
I am also facing similar kind of issue. Did you got any resolution on this?
I am trying to merge newly integrated sonar into the master branch but it is failing after raising the MR. Below are my observations
Case :
main-branch : not integrated sonar - No QG
dev-branch: added integration for sonar - QG green
dev - master: raised MR for master branch - QG red