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.
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.
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.
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
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.
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?