SQ 10.2 turn off rule severity is a breaking change

SonarQube Server / Community Build
1

Hi,

reading the forum nearly every day, i was very surprised to see that rule severity has gone with Sonarqube 10.2 after updating one of our test instances to Sonarqube 10.2 !?

Severities are all at once deprecated and the link still has 404, means i don’t know what are your intentions
https://docs.sonarsource.com/sonarqube/10.2/user-guide/rules
AFAIK the deprecated state means it will vanish during the next versions, but here it was deprecated and switched off simultaneously, means there is no time to adjust.

For us it’s a breaking change, preventing the update from SQ 9.9 LTS to SQ 10.x

Our use case is like that =
Using the latest Angular and similar, we are forced to go with the latest Sonarqube version, as a LTS version every 18 month is no longer up to date.

We have these agreements with our security team

  • all rules enforced by them get the severity CRITICAL to separate from other rules
    these rules are combined in a <Language> Security quality profile, i.e. Java Security
  • the teams use their own quality profile, but it must contain all rules of the related security quality profile
  • the teams use their own quality gate, but it has to contain the condition fail if Critical > 0
  • if issues for a rule with severity Critical, the security team is always involved, otherwise we Sonarqube admins, the language experts and the developers decide how to deal with it if i.e. it can’t be fixed for whatever reason
  • with every SQ update the new rules with category ‘Vulnerability’ are activated with severity INFO for 2 weeks to see if there are any problems, afterwards the severity is switched to CRITICAL
  • sometimes the security teams wants to change the default severity - but his ain’t possible anymore
    i.e. the rule has category Vulnerability and default severity Minor, but the security team has a different opinion and wants severity CRITICAL

How should we go on with these changes ?

After all i’m quite disappointed that Sonarsouce doesn’t ask or discuss with the forum / user base before taking such decisions.

Gilbert

9 Likes
2

I thought for sure you were wrong… turns out, I was!

Wow, I’m very surprised they took away the feature of customizing the Severity of Rules. This is huge.

image
image708×304 14.2 KB

Plus, the explanation given doesn’t sway me. We need this feature back!
https://docs.sonarsource.com/sonarqube/10.2/user-guide/clean-code/

3 Likes
4

Agreed - this is a huge change. We’ve customized the severity of some rules as well to tweak our quality profiles. This includes both SonarQube rules, but also external rules by the Roslyn analyzer.

You often reach out to your community to see how we’re all using SonarQube. Did this not come up? Either way, please reverse this change.

5 Likes
5

For me this change came out of the blue, didn’t see any hint in this direction before.
We have been using Sonarqube Enterprise since 2016, it is an essential part of our
workflows and is accepted and appreciated by our developers.

It took months to years for things to work out the way they do today, which means a lot of discussions, persuasion and patience.

Now we have a pragmatic agreement:
as long as the security requirements are met - see my first post, teams can decide for themselves how to use Sonarqube. I motivate our developers to use Sonarqube more extensively and they do, means they use their own quality profiles / gates, portfolios … etc.

But now with 10.2 => severities of rules can’t no longer be modified is a showstopper and
prevents us from updating :disappointed_relieved:
Changing / adapting our workflow will take time - not weeks but month - which ain’t possible due to many important releases towards the end of the year and lack of capacity.

While i appreciate the Sonarsource community forum, the webinars and the blog posts, i miss the transparency and proximity to the customer in important decisions.

Only two examples from the past, that led to negative feedback from your users

  • removal of the sonar.branch.target property in Sonarqube 8.1
  • the prominent quality gate warning “This quality gate does not comply with Clean as you Code” (as Sonarsource envisions) that can’t be suppressed

Going into discussion with the users before making such decisions would save both sides frustration, anger and the waste of time and resources.

Stances of the Product Owner | Scrum.org | Stances of the Product Owner has

The Customer Representative focused on helping others (Developers or others) to understand what customers need, what their challenges are, what pains and gains they have. Acting from this stance, the Product Owner tends to explain how our work affects customers, users, and business processes.

It seems there is a shortage of “… to understand what customers need, what their challenges are, what pains and gains they have.” right now !?
I understand and support your “clean code approach” but i don’t want to be forced / pushed, there is no one solution fits all.

What i’m missing in general is a transparent roadmap.
It’s not as easy as it was to keep track via Sonarsource Jira since your switch to Jira cloud and i know it’s not your fault because of Jira cloud restrictions, but it has to get better somehow.

For Sonarqube 10.2 - as i found out AFTER the update - Jira has
https://sonarsource.atlassian.net/browse/SONAR-20518

In the rule activation dialog for a quality profile it should no longer be possible to change the old severity through the UI.
We drop this field and add a notification message to make the change transparent to users.

the notification link is still 404 btw

https://sonarsource.atlassian.net/browse/SONAR-20517

It should no longer be possible to change an issue’s type and old severity through the UI. We mark them as grayed out and add a deprecation tooltip with the link to the documentation …

I’m not used to “deprecate and inactivate simultaneously” in a minor version :scream:
Now you see there are users that need to change rule severities and
“We drop this field and add a notification message to make the change transparent to users.”
is short-sighted and impractical.

Gilbert

2 Likes
7

I am also surprised by this change.

Since the Jira task was assigned to @Stan, maybe you can give us more info about it?

8

Hi @JBertrandRSE,

I understand your motivation here, but please don’t @ people not already involved in the conversation. In this case, Stan may have handled implementation, but he’s not responsible for the underlying decisions.

And in the meantime, the relevant folks have been pinged. Hopefully they’ll show up soon.

 
Ann

2 Likes
9

Any statement from the Sonarqube product owners / managers ?

11

Hi everyone,

First, I really appreciate your input and the fact you took the time to elaborate. We’re taking your feedback seriously.

We could have done a better job at informing you about the changes linked to introducing Clean Code in the product and explaining the reasoning behind them. We’re aware that there’s room for improvement in this area, and we want to be more transparent in the future.

Regarding the flexibility that was dropped, we made the change because we now have multiple severities associated with the new software qualities, which we will continue to extend. This means there is no single severity to change in the rule.

We understand that it has been valuable for your use cases and that some needs aren’t currently covered.

We want to understand your challenges and address the most important ones in the next SonarQube versions. In the coming weeks, we’re engaging in more discussions with our users around this topic.

Please help us get this right :pray:

Chris

7 Likes
12

Sorry about the 404; it was unintentional and is being addressed by SONAR-20606 (currently in Review).

The correct URL is: https://docs.sonarsource.com/sonarqube/latest/user-guide/rules/overview/
We are requesting a redirect now… (thanks for letting us know!!)

1 Like
13

A post was split to a new topic: Liven-up the 404 page

15

Please excuse, no, try to respect my bluntness, Christope.

I have read multiple threads and postings where challenges where described, already. Most of these, also had some reply from you in it, too :+1: This makes me presume you are aware of / gained (at least some) understanding of the challenges you created by mandating your changes onto your userbase.

So you seem to already have some level of awareness concerning the cause of the challenge you created for your userbase. Now find a way to re-insert the amputated flexibility when one wants to inherit/use a rule. (i know, easier said than done)

I, personally, am positively surprised by the amount of invested good will (time) by ppl who try to do that already. Please help us by being transparent about how you try to get this right, too.

Daniel

1 Like
19

Is there a way to tell before migrating what rules we may have adjusted before upgrading? We’re currently running 9.9.x

1 Like
20

Hi Daniel,

The feedback and discussions we are having are very valuable in understanding how the flexibility has been used. Many of the challenges we’ve talked about revolve around prioritizing rules to make the overall code better. This is something we were already considering important, and recent changes have made it even more crucial.
We’re actively working on a solution and will share details as soon as possible.

Chris

22

Hi @Laurie_Dening,
With SonarQube 10.2, all rules are now classified based on Clean Code attributes and software qualities. The rule severity is tied to the software qualities and has simplified values.
Existing severities can no longer be edited, but they are kept and are still used for evaluating the Quality Gate conditions.

23

Hi!

I was also surprised by this change and we also use Severity in our quality gate. I agree that this doesn’t seem like an appropriate change for a minor version.

The new multifaceted approach could probably be a good idea, but being able to override the classification you make still seem like a necessary feature (Sonar getting the classification correct for the context of every user doesn’t seem likely, or even possible).

I would also say that this change essentially makes Quality profile inheritance a misnomer. The only function of it now is to create a superset of rules.

Since almost a month has passed since the initial post can you elaborate on your plans for this? Is this seen as an edge case that you may try to support again in some way in a future version? Do you agree that it was a mistake to make this kind of change in a minor version and you’re working on some kind of quick fix? Anything like that would help our decision-making immensely.

Erik

4 Likes
24

Hi @Chris ,

now I have found some time to have a closer look.

indeed, as i wrote above

Going into discussion with the users BEFORE making such decisions would save both sides frustration, anger and the waste of time and resources.

Deprecating features is one thing, but deprecating and deactivating at once is a no go, never experienced that with any software :frowning:
Normally deprecating is a marker for “this will change in the future” but i’ll have time to adapt or intervent.

WRT to the clean code approach
What’s the motivation behind this all, i’m more than 100% sure it doesn’t stem from user feedback ?
You’ve already got a lot of (negative) feedback after introducing the prominent " This quality gate does not comply with Clean as You Code" warning, but nevertheless you went further.

Your Clean Code approach in all honor, but it’s your way, we don’t want to be forced to use Sonarqube
like you tell us we have to use it.
Until Sonarqube 10.2 there was enough flexibility for nearly every use case.
The simplifying of severities to high / medium / low is ok :+1: but taking away the categories and the possibility to change rule severities is the wrong way.

Our security team may have another opinion and wants to increase the severity.
Another example is the rule Java static code analysis: Track uses of "@SuppressWarnings" annotations
In Sonarqube 10.2 it has low impact, but we have severity critical for it.
code smells are whitelisted, but security rules not, see
Where is the documentation on how to suppress each kind of warning? - #3 by Rebse

Developers are used to the concepts of bug, vulnerability, code smell for years - those are established terms and concepts - but the terms of consistent, intentional, adaptable, responsible code are to academic.

Issue type deprecation and severity changes

As part of this change, we will be deprecating and gradually removing our previous notion of issue type (bugs, vulnerabilities, and code smells). Also, severity will have simplified values: low, medium, and high. Additionally, we are extending severity to multiple severities per issue, one per software quality.

Multiple severities per issue adds a needlessly complexity.

For the quality gates, everyone understands conditions like critical issues > 0 at first glance, but if i have to use ratings i need a translation first, what does rating A mean … etc.

After all, i already presented our workflow in my first post and why the changes in Sonarqube 10.2 are a showstopper. Also i have no idea for a migration path, it just won’t work.
Otherwise we’re on the latest Sonarqube version for quite some time, but now …

I sincerely hope you will reconsider the whole thing thoroughly.
Was project manager in 2015 for selecting a tool for code analysis and I was glad Sonarqube made it,
but I don’t want to be project manager again to find a replacement for Sonarqube in 202x.

2023-10-27_16h50_04

Gilbert

5 Likes
26

Hello,

Thanks for sharing your thoughts. I’ll set aside the broader Clean Code discussion for the dedicated thread and focus here on addressing the flexibility concerns you’ve raised.

We believe in the importance of a step-by-step approach and really appreciate your feedback every step of the way. That’s precisely why we’re introducing changes incrementally in the 10.x series.
Some of you rely on this flexibility for some use cases that currently lack alternatives. I acknowledge that deprecating and removing this flexibility all of a sudden has caused friction for some of your current workflows.

From the discussions with users, it’s clear that customizing rule severity within a Quality Profile primarily serves the purpose of prioritizing rules to improve the overall code quality. To help teams define their priorities easily and explicitly, we are working on enhancing the method for configuring these priorities within Quality Profiles and streamlining Quality Gates. However, in the upcoming version, the complete solution won’t be available just yet.

In response to your concerns, and to make the transition smoother, the next version will restore the ability to edit the old rule severity within a Quality Profile. The deprecation notice will remain in place to keep you informed about a future change.

Again, we’re working on a more comprehensive solution and, as we make progress, we’ll keep you posted with updates.

Chris

8 Likes
28

Hi @Chris,

Deprecating and deactivating at once != step-by-step !?
This is a showstopper for us and maybe many other customers relying on the latest version.

Sonarqube is doing a great job so far, what is the reason for introducing new terms like
consistent, intentional, adaptive, responsible code, and replacing established/common terms like
Bug, Vulnerability, Code Smell - which are also used by many other tools ?

IMO it would be ok as an optional way of using Sonarqube, similar to the ‘Sonar way’ quality profiles.
As a proposal for new users, starting with Sonarqube - in fact many users start with a copy of the ‘Sonar way’ quality profiles.
But for customers who have been using Sonarqube for a long time it breaks existing workflows.

This means that the reversal will be temporary and the severity edit will vanish in the future for sure ?

Gilbert

29

We (me and my company colleagues) were also very surprised realizing that an important functionality of SonarQube was removed.

Why overwriting the severity and categorizing are important to us?
You are defining the rules and we try to use them all. But we do not always agree. Some times we faced rules which do not align our experiences.
So, in the past we decided either to disable the rule or to reduce the severity. The latter one we use for rule which we like at all but which are too restrictive. Now, we only have a binary decision: use or do not use. :frowning:

We have a lot of project with a long history. They were existing before SonarQube was available…
To find a good balance between “clean code” and “effort to handle more than 20K issues” we decided to introduce different profiles according to the combination of type and severity:
Basic: Blocker and Critical Bugs, plus Blocker Issues
Advanced: Critical and Major Bugs and Issues
Full: (Nearly) all rules
With the planned change we only have available the “new severity”. Using this we would get a complete new set of rules for “Basic” and “Advanced”. I do not know how to communicate this to our users!

I value your attempt to revise the rule categories, but please ask users before introducing such big change. At the moment I really does not catch why the new limited categories are better than the old one.
The only problem I faced in the past was the mapping the C# compiler issue levels where only “none”, “info”, “warning” and “error” are available which does not align to the SQ severities.

6 Likes
32

Hi,

Thanks for providing detailed explanations about your use case, @lg2de,

Regarding customizing the severity, SonarQube 10.3 is now available which restores this capability. We realized that you were using it, that we broke it for you, and we acted on your feedback.

This means that the reversal will be temporary and the severity edit will vanish in the future for sure ?

We plan to remove it only after we come up with a better solution that will answer your use cases.

More generally, we understand that customizable severity is used to enforce priorities on overall code, and for other diverse use cases we’re still hearing from. However, this flexibility was not explicitly built for that purpose. We believe that customizing the severity blurs the line between organizational policy and code quality assessment.
Of course, you should own your code policy and have the autonomy to define it as you like: you know what you need better than anyone else. That’s why we aim to develop a dedicated solution for setting and enforcing your policy on the codebase.

Chris

4 Likes