We have a single SonarQube project created for our repository, with SonarQube scanning tiggered via a gradle task.
One of our requirements is that we want to have a check on each of the Quality Profiles above and return the quality gate result:
Bugs
Code Smell
Vulnerability
Security Hotspot
As of right now, the stages in our CI run sequentially: Bugs Check → Code Smell Check → Vulnerability Check → Security Hotspot Check which as such has increased the CI time a bit.
We want to to be able to do this in a parallel fashion (without increasing too much time in the CI pipeline).
Is there a way we can do this in SonarQube? Or via gradle?
first: i am by no means an expert, so nothing i say (edit:) should be understood as truth by default
second: i think your question concerning parallelization is to be solved in CI (a.k.a gradle or build pipeline)
third: for any SQ-Project with a unique sonar.projectKey the Qualitygate to check against is configured in the server. If i would want to use different Quality Profiles i would
either create different Projects (with differing unique projectKeys) and each Project gets its respecting Quality-Settings (Gate/Profile)
or would need to (manually or via WEB-API) switch the Quality-Settings before a new scan is submitted to the server
What i did not understand is the following:
Could you elaborate how your QProfiles and QGates are configured? I am not able to envision anything that would work like you described. But my vision already is near-sighted, so i am curious to learn
Daniel, We have configured a quality profile and quality gate per type of issue (Bugs, Code Smells etc) but we wanted to check them individually instead of together (one of the requirements we got)
Creating multiple SonarQube projects for each check is an option i had not considered, that’s one approach i can share. This way they can be triggered in parallel, let me implement this and check it out. Thanks for this approach!
Vivek, Yes we were using a single Quality Profile + Quality Gate in our pipeline, but wanted to have separate checks on each type of issue.
I’ll be checking out the approach shared by Daniel and see if that works for our requirements.
hi akshay, i now have a bit better understanding i think … actually i was thinking along that lines, too. some years ago. when i was envisioning my plan on how to tackle using sonarqube “better”.
i had something planned along the line of “onion-layer-style” …
buildbreaker-QG/QP
fixable-QG/QP
kitchensink-QG/QP
Then feedback reached me, that this setup was perceived as too tedious by some … and additionally i realized, that if i create those new projects in a commercial distro it would count as separate (and as such creates 3x a hit on the commercial LOC-Limit)
This made us rethink and just focus on one QG/QP, like vivek suggested … if you want to get statistics on different things, you could use the web-api to extract relevant-findings-data, for example.
