For many years, SonarSource campaigned for the use of a dedicated step in the release pipeline to check the quality gate status and prevent the deployment of bad quality code, instead of failing the analysis step if the quality gate was red.
We consider that the result of the analysis should not prevent you from doing other stuff in your pipeline (running scripts, running tests, etc).
So, we provided this kind of solution for Jenkins, Azure Pipelines.
With GitLab, we had to use a workaround due to technical reasons, and thus, introduced an analysis parameter allowing the user to fail the analysis step if the quality gate status was failed.
This approach has multiple drawbacks (increase of step duration, overload of your SonarQube instance by polling it, fails the step if the quality gate is red, even if the actual analysis is successful).
However, at the same, it means that we leave a lot of users who don't use Jenkins or Azure Pipelines without a solution.
We know that a lot of users are asking for an "official" way of doing this, instead of having to script themselves the poll of the quality gate status.
This is why, even if it's not the recommended approach, we want to document the existence of the sonar.qualitygate.wait analysis parameter.
We want to document the existence of the sonar.qualitygate.wait analysis parameter.
We want to provide it as a way of failing the CI/CD pipeline when you don't use any of the following CI tool : Jenkins, Azure Pipelines.
We want to be clear that
- this is not a recommended approach
- this will make the analysis step poll the SonarQube instance and wait for the quality gate status
- this will increase the pipeline duration
- this will fail the analysis step if the quality gate is red, even if the actual analysis is successful
- the user should be cautious with this parameter and use it only if necessary