Problem or Opportunity: We have encountered a limitation following the upgrade to our quality gate conditions in SonarQube. Previously, we could establish different severity expectations. However, the new system only permits specifying the number of issues, which is less practical.
Why It Matters: In the old system, we could define Ratings from A to E, enabling us to set a threshold, such as “B.” This meant the gate would fail in the presence of major, critical, or blocker issues but not minor ones. This granular control is essential for gradually increasing quality standards.
How It Would Look in SonarQube: The ability to set severity levels directly on the quality gate, similar to the previous system, would allow us to fail the gate based on the presence of certain severity issues rather than just a numerical count.
Why It Should Be a Priority Now: The lack of granularity in the current system makes it challenging to progressively raise our quality standards. While we understand the ‘clean as you go’ approach, SonarQube highlights old issues on new code when that piece of code is touched. Since we use sprints and commit to a certain amount of feature work, we cannot fix all the issues as we go. However, we can focus on the more important ones.
I believe this is a common situation that can benefit many companies, allowing them to improve code quality gradually.
I’m curious to hear more about the Quality gate settings you previously had that you’re no longer able to configure. Can you provide a few more details?
Which version of Sonarqube are you currently on?
Do you have some examples of conditions you wish you could configure in the new version but are unable to?
Is the issue that:
– you cannot configure the quality gate conditions you previously had at all OR
– the quality gate conditions you want do not comply with Clean As You Code
I’m on SonarQube Enterprise Edition v10.5.1 and I still have the ability to create quality gate conditions based on ratings (e.g. “Reliability Rating is worse than B”). Based on the Clean As You Code documentation, A ratings are valid conditions for a compliant quality gate. My SonarQube instance has an array of quality gates configured. SonarQube gives us the icon for the ones that don’t comply with Clean As You Code, but we are still able to use them as expected. My understanding is that the Clean As You Code methodology is recommended and is the new focus of some SonarQube features, but it is not mandatory.
Yes, we’d like to configure Quality Gate the way it doesn’t comply with “Clean as you Code” approach.
We’d like to set Quality Gate to fail in case there’re high and medium severity vulnerabilities and/or high severity bugs.
Currently I can set it up as: Option1: 0 vulnerabilities and 0 bugs
It’s too strict for us. Option 2: A, B or C Security and Reliability Ratings
The result of it is unexpected. Current documentation states following: Security Rating (security_rating )
A = 0 Vulnerabilities
B = at least 1 Minor Vulnerability
C = at least 1 Major Vulnerability
D = at least 1 Critical Vulnerability
E = at least 1 Blocker Vulnerability
So it’s using minor, major, critical, critical, blocker instead of high, medium, low severity, and we don’t know how it would translate.
Does mapping apply only to bugs and vulnerabilities?
I looked through all the issues, and seems like bugs and vulnerabilities map correctly, but code smells don’t. I saw some medium severity code smells that were minor.
That mapping should have been applied to code smells as well. Where the mapping doesn’t appear to have been applied, I think that must be because the team has updated the severity deliberately.
Are there particular rules/types of rule that you think will be a problem?
this means the mapping uses the default severity of a rule ?
We changed some severities of rules with category vulnerability, because our security team
had a different opinion, i.e. the rule has default severity Minor but they want Critical.
Yes, if you are using custom severity you will also find mappings are different because we did the move to High/Medium/Low based on the default severity of the rules.
icon for the ones that don’t comply with Clean As You Code, but we are still able to use them as expected. My understanding is that the Clean As You Code methodology is recommended and is the new focus of some SonarQube features, but it is not mandatory.
