Better Quality gate and profile management for automation

Hi guys, I’ve been in a bit of a pickle. Mainly because I kind of need this feature to make my life a bit easier.


Right now, we built an automated pipeline in jenkins with shared libraries, and we have different stages from testing, scanning, building artifacts, all the way to automatic deployment on openshift/kubernetes for about 60-100+ services and increasing.


The problem I’m having is, our development cycle. Devs want to see if their code runs on the dev namespaces, but also check for owasp vulnerabilities and code duplication. Testers wants to view the code coverage and also make sure that there are at least 50%+ unit tests and integration tests. Prod wants all of that but code coverage set at 80% and other additional rules.

Possible unfeasible solution

I can set up a dev profile, test profile and prod profile through the UI for all 100+ services, but it would take me forever, be very tedious and I’ll refuse to do it like that.

Feature hopes

I was hoping that we can automatically assign a project to a specific quality gate/profile through the sonarqube webapi. Problem is it’s hard to navigate the api parameters through the docs, not to mention there are hidden parameters and functionality as well.

It would be easy to assign, because our pipeline builds depending on the branch. For example, “feature” branches are Dev, “develop” branches are for test and “master” branch is for production.

So auto-assigning a specific project to a specific quality profile would be nice to have, please add the feature.

PS: If anyone has a workaround, I would love to know.


Welcome to the community!

Yeah, this is fair. Really, the easiest thing to do here is make the change you’re after via the UI and use your browser’s developer tools to eavesdrop on the call that’s made.

You’re right about this too, & if you include such parameters in your automation, you do so at the risk that they’ll change from version to version without warning. Once you determine what your call-of-interest is, you should use the docs to double-check that it’s not using any hidden parameters. If it is, you need to determine whether they’re deprecated (we shouldn’t be using them either, so please do drop us a line!) or internal. If the latter, it’s likely that they’re ready for prime time but we just forgot to change the marking. If so, your asking about them here (well, in a new thread) is likely to prompt us to update.