Allow project administrator to manage Quality Gate configuration

We would like to have project specific quality gates. The project administrator should be able to modify the gate configuration (e.g. maximum number of allowed issues) for project only. It should not be able to modify all other quality gates.

Currently there is only a global privilege to administer quality gates.

Is it possible to implement feature to allow specific user or group to administrate specific quality gate?


I’ve moved this thread to the ‘Suggest new features’ category, because what you describe isn’t currently available. BTW, it is possible for a project administrator to choose from the existing quality gates. But it’s not possible (and not actually likely) to create project-specific QGs. Why? Because we feel you should really be enforcing the same standards across the entire organization, which should be possible if you focus on New Code.


You are right, theoretically!

In real life I manage a server with two kinds of projects:

  1. Projects/Products development started before we found SonarQube. Here we have list of existing issues between 1000 and 45000! And we do not have the power to solve all issues in the new future. This is not a business value for the Product Owner!
  2. Projects development started after we have introduced SonarQube. Here we do not have a list of old issue, we could defined Quality Gate to be used in (nearly) all projects.

You may state that we can remove the limit for “maximum issues”. But the project administrator would like to reduce the maximum number every time it is possible. Over the time we expect to get fewer issues in ALL projects.

Because this maximum configuration I need project specific gates or similar option.

1 Like


This is actually the beauty (one of them!) of using New Code metrics. Let’s say you’re watching the total number of Bugs. In my project it’s 51, so my individual Quality Gate has been set to fail at Bugs > 51. So if I

  • add 1 Bug -> QG Fail :white_check_mark:
  • fix 2 and add 1 -> QG Pass :x:

This isn’t what you want to happen. So instead use ‘on New Code’ metrics. With a QG condition on Bugs on New Code > 0 then if I

  • add 1 Bug -> QG Fail :white_check_mark:
  • fix 2 and add 1 -> QG Fail :white_check_mark:

That’s why I say that with an “on New Code” Quality Gate you really can apply the same criteria across all projects. And with this approach you will gradually reduce the outstanding technical debt in the normal course of doing business, assuming your developers don’t ignore existing issues in the code they’re working on.

But okay, if this still doesn’t do it for you, your request is still listed as a suggested new feature. :slightly_smiling_face:


1 Like

In theory you are right, again.
But there are situations where we have to live with one or two new issues, e.g. TODOs not fixable in current sprint. So, we accept some time a failed quality gate if the NEW ISSUES are uncritical.

Not having a TOTAL MAXIMUM the list may grow step by step.

Your feelings are your personal matter - do not try to enforce them on your users. Do not consider them as idiots unable to make own decisions.

In a big organization there are many kind of projects with various quality requirements and on different stages of development.

Hey Lukas,

I’m curious – are the issues that you accept as non-critical (and thus, when they fail the Quality Gate, you ignore the Quality Gate failure) typically INFO level issues (like fixing TODOs)?

I’m asking because there might be Quality Gate conditions you can set to get around INFO level rules triggering Quality Gate failure, or perhaps an argument to be made that INFO level issues shouldn’t trigger Quality Gate conditions regarding issue count (since they are supposed to just be informative, no action is expected). I await your feedback before I invest into that argument. :slight_smile:

What happens when the list hits the total maximum? Is there suddenly time to bring that total down? How does a project administrator judge what the total maximum should be?

I think, I will never configure to ignore INFO issues at all. Instead it is always an individual decision.

From time to time we reduce the value for “maximum number of issues/bugs”. I never want to increase the number again. Over the time I hope to reach “0 issues and 0 bugs”.