We have decided to move from 3 to 5 levels of severity at the software quality (security, reliability, maintainability) level.
You may have noticed that ‘Info’ and ‘Blocker’ have appeared as possible filter values in the UI. We listened to your feedback about the value of five levels of severity at the rule level, and we are extending this additional granularity at the quality level by adding an ‘Info’ and ‘Blocker’ level at either end of the existing low, medium, or high severities.
At the moment, we don’t have any rules with these severities, but over the coming months, we will start using these levels of severity to provide additional insight into the level of impact a rule might have on a particular software quality.
You can find out more about these severities here.
Please let us know if you have any questions or feedback.
John
Edit: (I’ll add as a response as well so that it is easier to spot this update)
We wanted to add some additional information on what this means for the APIs. When querying rules or issues, you may start to see INFO and BLOCKER appearing as statuses at the quality level (i.e. a rule might have a reliability severity of BLOCKER). It is also possible to create rules/issues with these additional severities. These APIs in particular are affected:
api/issues/*
api/rules/*
api/projects/export_findings
api/qualityprofiles/compare
api/qualityprofiles/changelog
This is the case for both SonarCloud and SonarQube, starting with the 10.7 release.
The linked document has an error. The “LOW” severity level description is also pasted at the end of the “MEDIUM” severity description.
The issue documentation was not updated. It still states that “There are three severity levels” and only describes “High”, “Medium” and “Low”.
Also the question is, if the “Severity mapping” from the legacy severities (“Blocker”, “Critical”, “Major”, “Minor” and “Info”) to the current ones is correct?
The Reliability and Security ratings still rely on the legacy severity.
There’s still no way to set up Quality Gate conditions based on the current issue severities and/or software quality classification, as the metrics for those are defined as DATA, (combining all severity quantities into an object). As opposed to the metrics for the legacy severities, where there simply was a separate INT metric for each severity, supported by the Quality Gate conditions.
Those limitations seem to be a bit more important, than the severity granularity.
Thank you for pointing out both the mistake on the software qualities page, which has now been fixed and the lack of an update on the Issues page.
The issues docs have recently been redone and are now a section linked here. The old page is archived and should not be visible in the page tree, that’s a bug on our end.
So now all the links to old documentation pages are broken (as they don’t redirect to the new ones covering those topics).
Also although you have spent time, to create a whole documentation section for issues, and those new documents clearly show the legacy issue type and severity on a screenshot, they blatantly ignore them and don’t provide any explanation on what those are, while the previous documents did.
So now, when you read about metrics related to issues, you have no idea what the blocker, critical, major, minor, info mean (or get them confused with the current issue severity levels, which are not the same), and the same goes for understanding where the terms “bug” comes from in the reliability rating or “code smell” for maintainability rating (and metrics) or “vulnerability” for security rating. That’s unless you stumble upon them in the documents specific for completely different things, like security hotspots mentioning deprecated issue types or the document on rules, which actually describes the deprecated issue types and how legacy severity levels are determined (not covering the current ones) and only mentions that the types are deprecated somewhere at the end (crammed between severity and rule tags), without mentioning the current severity levels at all (so also how those are determined).
All in all, the documentation should be updated consistently and what is there currently in the system should not just be removed from the documentation, as it’s clearly still relevant.
And yes, I noticed you have ignored the other half of my comment and - as you probably noticed - I’m not very happy about that.
You have built a great system for detecting problems in our code. Good enough for us to pay you for it (and we do).
Unfortunately you do lack in telling us how to use it and actually making it work with how we do our job and thus how we need to use it, which makes it very hard to justify to our colleagues and coworkers the pain we and they are going through, when introducing and using it.
I answered what I could since I work on the documentation at Sonar. I can help with your concerns with the docs, hence why I addressed that part of your reply.
I will follow up with the team member who worked on the new issues section to make sure a request for redirects was submitted.
I will share your feedback with the entire docs squad on ways we can improve and do better on the process we use to update the documentation.
Your point about the reliability and security ratings and quality gates not using the new concepts of severity at the quality level is totally fair. We are working on a plan to make it possible to work in terms of these concepts at the rating and quality gate level, if a user wants to, but don’t yet have a date by which we expect this to happen.
We wanted to add some additional information on what this means for the APIs. When querying rules or issues, you may start to see INFO and BLOCKER appearing as statuses at the quality level (i.e. a rule might have a reliability severity of BLOCKER). It is also possible to create rules/issues with these additional severities. These APIs in particular are affected:
api/issues/*
api/rules/*
api/projects/export_findings
api/qualityprofiles/compare
api/qualityprofiles/changelog
This is the case for both SonarCloud and SonarQube, starting with the 10.7 release.
I wanted to come back to you with an update on this.
We recently provided an update that we would be adding custom severity for rules and issues back into SonarQube Server (formerly SonarQube). We are currently evaluating software quality severities for SonarQube Cloud with the principles mentioned in the linked post in mind and will provide further details in the coming weeks.