Add properties for setting quality gates and profiles

Currently the only way I’m aware of to set quality gates and quality profiles is either through the UI or API.

It would be really useful if we could set these as a property when calling the cli. (I believe sonar.qualitygate used to exist but was deprecated for some reason.). In a matured CICD process you need to be able to automatically set these quality profiles and gates for groups of projects and ensure that all the projects are held to the same standard.

We are technically able to do this through the use of the APIs, but I believe that this is a pretty common need and shouldn’t be left to the users to build a maintain their own custom tools to set these.

1 Like

Welcome :slight_smile:

this might be possible in an open environment, but not for Enterprise customers - think of banks or insurance companies with strict safety requirements .

It is bad enough that “sonar.exclusions” can be used as a scanner property

and this should still be considered


1 Like

What would you suggest then? In a properly automated CICD environment the gates and profiles should be set before the first scan runs. If you can use the defaults for your environment then it works just fine but that definitely isn’t always the case.

1 Like

In a proper CI/CD environment you should / will have sane default settings that cannot be easily changed at will.

What is meant by this ?

We have multiple different teams within IT using the sonarqube instance. A lot of us will use the same quality profiles but sometimes we need to use different ones. Some examples would be for xml and yaml files. Different teams use these filetypes in different ways so they may want different quality profiles.

You can only have one default quality profile for a file type so one of those teams will have to manually set their projects to use a different quality profile.

We also have many teams that share one Sonarqube instance and it’s clear that one quality profile or quality gate does not fit all.

But those settings should be part of your provisioning workflow i.e. creating a Git repo, Nexus/Artifactory repo, Azure Devops team, Sonarqube project with appropiate qualitygate, quality profiles … etc. and be reserved for admins only.

To provide those settings on scanner side would create the danger of abuse or accidently use the wrong settings.

1 Like

We need the provisioning workflow to be automated. Everything else can be setup for a new project in sonarqube by just running the scanner with the proper properties in our cicd pipeline.

However, to property get quality gates and profiles setup I’m now forced to build and maintain my own tool to automate this process. It would be much simpler to have it as a property in the scanner even if some sort of admin credentials needed to be passed along with the scan command

1 Like

In fact it’s very easy to incorporate the creation of a Sonarqube project in a provisioning workflow, as Sonarqube ships with a great rest api.

I’ve seen many different things over years, email driven, webservices with wizards … etc.
Simply create a technical user with admin permissions for all tools involved, use their rest apis and you’re done.

Having those properties as scanner side properties will end in chaos.
And finally, assuming you use Jenkins or similar, you may feed the related Sonarqube rest api calls
with values set via pipeline properties to let the teams decide it.

1 Like

Hi @emorey.splunk

Welcome to the community!

Would you mind explaining how you create your projects? Is it happening via import from the DevOps Platform (& so maybe the ability to choose Profiles &QG at that time would be helpful), or are they created automatically on first analysis?


As an additional use case …

I work in a large company with many projects, and multiple ways of scanning as part of the CI process, and we need this to be automated and straightforward. Projects are created as part of a scan. In particular, Engineers don’t usually have project admin access plus can’t ask for it ahead of time since it won’t exist. Manual steps like setting a quality gate, setting a project tag, or adding to a portfolio require opening an escalation ticket to a service team to take the manual steps (and again, can’t be done ahead of time). What a waste of time for everyone!

Given the large number of legacy projects, our default QualityGate must enforce our minimum standards. However we want to set a much higher bar for new development, so need to be able to specify a different QualityGate on creation. We also want to bring legacy projects up to current standards as resources permit, so it would be nice to change the QualityGate with a new scan (although automating this is less priority)

Note: to answer one of the questions I see here: no, engineers are not allowed to create arbitrary QualityGates. We have an Application Security group who are the only ones who can touch that.

We need a new scan to be able to automatically specify one of the existing QualityGates as part of creating a new project

1 Like

While I understand your replies assume heavy dependence on a servicing team to do manual provisioning ahead of time, many of us find that just introduces impediments, adds unnecessary work, does not scale efficiently.

I want to set a QualityGate on scan, automatically as part of the scan, so I don’t need project admin, I don’t need to open a ticket, I don’t need to waste time of a service team.

While I understand your concern over the security of the process, we have an Application Security group managing the QualityGates, and no one else has the privilege. The default QualityGate realistically has to be the lowest bar. I want my new project to use one of the higher bars already configured when I create it, and without all that overhead of coordinating manual work

1 Like