Be able to add/remove conditions to the quality gate without warning


Many of my customers want to define their own quality gate. From my point of view, there is no single quality gate that fits all companies, it is common to adapt the quality gate according to the company’s strategy. That’s why I think SonarQube offers the possibility to define a quality gate, it’s great.

“With the Clean as You Code approach, you should always focus on new code, so we do not recommend adding conditions for overall code to your quality gate.” is what is stated here Clean as you code..

Ok, but what if my client wants to focus on the global code as well for a few months, because :

  • he has started to analyse an old project
  • this old project is still alive and will live for years
  • he has discovered with sonarqube many bugs, vulnerabilities and code smells in the old code
  • the number of code smells is too large to be processed
  • but the number of bugs and vulnerabilities is not so high and can be reasonably handled.

So he wants to

  • Adopt clean as you code, the quality gate focuses on new code and breaks the pipeline: done via merge-request analysis as all new code comes from merge-request…
  • But he also plans to remove all the bugs and vulnerabilities from the overall code (a few hundred) over a 3 month work period.

As he likes things visual, he wants to see the quality gate failed on the main branch (visually from sonarqube) but without breaking the pipeline on the main branch as all bugs and vulnerabilities have not been addressed. So

  • -Dsonar.qualitygate.wait=true on merge-query pipelines
  • -Dsonar.qualitygate.wait=false on the main pipeline for 3 months.
    At the end of the 3 months, the quality gate on the global code will be removed, -Dsonar.qualitygate.wait will become true everywhere and will only affect new code.

What do you think of this 2 phase implementation on legacy projects? Do you recommend anything else?

Also, during the 1st phase when my client adds global code on Quality Gate, he sees this warning and it is disturbing, is there any way to disable this warning?

The context is :

  • On-Premise
  • Developer Edition
  • Version 9.9

Thank you for your comments

Best regards,

1 Like

Hi Arnaud,

Thanks for taking the time to explain your problem in detail.
This is an interesting idea, but I see a few significant risks with this approach:

  • The check running on your main branch pipeline would not really guarantee that only new code that is clean reaches production. You would effectively prevent merging new code that is not clean to the main branch, but you wouldn’t really make sure that the release/deployment is blocked if for any reason the new code on the main branch is not clean.
  • The approach may lead to diluting the attention that developers attach to the Quality Gate. I think it’s better to consider the Quality Gate as an actual gate that can not cause any debate on the conditions to prioritize and that could be finally ignored by developers. For that purpose, we recommend keeping the focus of developers on new code only.

The Clean as You Code approach proves to be a great tool to improve the overall quality of the code over time, so I don’t have any suggestions on a way to schedule a temporary remediation effort on the old code. I think that users who are interested in doing it are generally handling it as a separate project, drawing a plan so that they can prioritize the issues they want to fix.

Also, during the 1st phase when my client adds global code on Quality Gate, he sees this warning and it is disturbing, is there any way to disable this warning?

The warning is currently not dismissible. Would you have more details about why this warning is a problem?


1 Like

I’m using this post to make a point about this.
We are currently using version 9.4 and are in the process of testing 9.9 in uat before doing the production upgrade.
As a daily user of the application for several years we are well aware of your concept of Clean as you code.
We have adopted the approach encouraging the application of good practices on new code produced. Indeed, this encourages developers to get more involved on a daily basis.
However, we find the new warnings particularly visually polluting and infantilizing.

We have been using for a long time several Quality Gate adapted to multiple projects belonging to several teams working on multiple projects (metrics and thresholds balancing quality requirements and business reality).
Being able to push teams to work on the quality of their legacy code as they go along thanks to the metrics applied to it is also a useful and powerful lever.

It would be really useful to be able to simply deactivate your methodological warnings to focus on qualitative warnings according to our Quality Gate definitions.


Hey @Stuaalto

Thanks for your feedback–we expected there would be some, and we’re eager for it. I have moved your post to an existing topic discussing this so that the feedback can be consolidated.

1 Like

Hello Bertrand Rochette,

Thank you very much for your feedback. I understand your needs around improving legacy code.
We will continue monitoring feedback on this subject.

Hello SonarQube team,

Congrats for the LTS release, it rocks!

However, I have an annoying warning message on Quality Gate:

I think I’m experienced enough with quality gate to tune it as I want.
Is there a way to dismiss this warning?

with :heart:


Hello Xavier,

Thank you for your feedback.
Currently it is not possible to dismiss this warning.

However, as far as these base Clean as You Code conditions are preset in the Quality Gate, the yellow warning box will not be displayed. Your current quality gate may be allowing accumulation of issues. Please note that coverage and duplication are still fully tuneable.

Hi Chris;

Thank you for your feedback.

Its just noise, but its important for us, the main interface must be clean and developers should not be polluted by warnings.This tends to trigger endless discussions in the team :wink:

But don’t worry its fine, we will just ignore this warning for few weeks !!

I fully understand your point of view on the notion of quality gate and new code. Do you give up the technical debt story and focus on the clean code mindset ? Because we were using SonarQube as a tool to control a part of our global technical debt. The mindset is: today this piece of code seems to be clean, but later it can become a problem and need to be refactored.

  • We need to save time for developers to treat this debt, but we have to fight with project owners who do not understand nothing about technical debt, that’s why I try to erase everything that tends to say “its not more important that new features”. By extension, the warning that we are talking about can conduct some people to say “hey look, nothing is more important that new stuff” :wink:

  • Also, what if adding a new rule related to security vulnerability after the product already deployed in production ? it makes sense that the next pipeline will fail if it has been found anywhere in the code, not only in new code, but maybe new rules are already included in new code report ?

Best regards



Hi Arnaud,

I see your needs around quality of overall code.

However, Clean as You Code methodology will focus on new and changed code.
This doesn’t mean that your needs on overall code is not important.

Thank you very much for the detailed feedback. This helps.

Hi Vivek,
I mirror the concerns from Arnoud. I find it also a bad customer experience to make this not optional. We have a lot of teams how are still on the journey to Code Quality and it not helpful for them to get directly the sledgehammer of thinks they have to take care of. In addition you should allow customers to modify the definition of Clean as you code since there could be different definitions.

For us it would be important to hear if and when we would be able to customize / deactivate this otherwise we will very fast loose our internal userbase to other solutions which are more friendly to use.

As an addition we are using the Enterprise version.

Best regards



I have also received many feedbacks from our teams after the upgrade with this warning.
The worst part in my opinion is that we have already conditions on new code but instead of ratio we have decided to use the absolute numbers. Both have pros and cons but now I have to add useless conditions just to get rid of the warning

And we have also gates that have lower expectations on purpose, in order to onboard projects and be sure they are analyzed (better to have visibility than nothing). For those, it will not be possible to remove the warning.

So it’s interesting to have recommendations but here it creates noise and doesn’t help.

Best regards