SQ 10.2 turn off rule severity is a breaking change

SonarQube Server / Community Build
34

Hi @Chris ,

the year is drawing to a close and it’s time to make the last refinements for projects in 2024.
Sonarqube is an essential part of our workflows and i have to make statements about whether we can continue to use Sonarqube as before.

Hope you’ve really understood the needs of your userbase, you’ve missed to ask before so far.

I’m missing the details and updates about your plans, what’s going on at your side ?
Better inform us ASAP before we are faced with new facts !?

Please give us some update, we all would like to know what’s going on and what we can expect.

Did you think about my proposal, making the Sonarqube way of clean code optional similar
to Sonar way quality profiles or quality gate ?

Gilbert

38

Hi Gilbert,

You will be able to continue relying on customized severity. We are exploring other possible solutions but are not yet ready to share more details at this time. Rest assured that we are mindful of not disrupting the existing workflows.

For updates, we’ve added a portal card to our roadmap, inviting other users to express their needs and enabling those interested to stay informed about our progress on this topic.

Regarding Clean Code in our products, I suggest continuing the discussion on the dedicated thread.

Chris

2 Likes
39

Hi Chris,

I think currently i cannot see how many fancy buttons got pressed nor the maybe added comments (tried to peek at a different card with presumably 10 comments and did not find any further info).

Is this just a second way of (this time one-way-) communicating (with you only)? (or did just noone press a button/enter a text comment in any of these cards? :thinking: :person_shrugging: )

Anyways, (soon-ish) happy new year :tada: :partying_face:

1 Like
40

Hi Daniel,

Happy New Year!

We present portal cards to keep everyone informed about the topics under consideration and to encourage sharing use cases, even for those who may not feel comfortable posting in the community. This channel frequently provides valuable insights that are not publicly available, complementing the discussions happening here.
Of course, we remain happy to answer suggestions and engage in further discussions directly in the community forum.

Chris

1 Like
42

Thank you for taking the time to explain your reasoning :+1:

Do i stay informed about your progress on this topic by reloading the page? If so: when should i reload it? If not: how else? :thinking:

I’m really curious how this is gonna work out in the end. I am still not feeling well about this multi-channeling but pls refrain from replying here in thread. (in multi-channel-tradition: you can send me a PM if you want to discuss this further^W^W^W give me tips on how to stay informed :slight_smile: )

cheers
Daniel

1 Like
43

Hi Daniel,

We seem to have diverged from the initial topic. A last word maybe to clarify a bit more about what this portal card enables: if you provide your email on the card, you’ll receive a notification whenever we post updates there. We’ll also try to keep this thread updated as we make progress.

Chris

44

Hi everyone,

I’m pleased to share an update on the topic.

We’ve created a dedicated solution that will allow you to prioritize specific rules within a quality profile. You’ll be able to set a condition on the overall code to enforce a policy across your codebase, resulting in a quality gate failure in branch analysis if any related issues are detected.

This solution, shaped by the feedback and insights from our community and various interviews, is designed to meet the primary needs of large and advanced organizations, and will be introduced in the upcoming SonarQube 10.6 release, available in the Enterprise Edition and above.

I want to thank everyone who took the time to articulate their needs, investigate the issues, and help shape the solution. Your input has been instrumental in developing the solution.

Chris

2 Likes
45

Thanks for the update, Chris.

What’s not clear to me yet: is this now intended to replace the possibility to change the severity of rules or is this an additional feature?

46

Thanks for your question, Jochen.

This solution is designed to offer an alternative to the need for custom severity, addressing the primary need you’ve expressed.
The old custom severity is still available to facilitate the transition, but it is planned to be phased out in the long term.

Chris

47

Chris,

When you say the old custom severity is still available, does that include the original 5 values (Info, Minor, Major, Critical, Blocker)? Or just the ability to modify the Severity in the profile with the 3 new values (High, Medium, Low)? What values will we see in the Severity dropdown after applying the 10.6 upgrade?

48

Having a way to fail the quality gate for specific rules is great, but you missed the opposite:
Having a way to not fail the quality gate for specific rules.

We used the info severity for rules like: “Track usage of Todo”
Those rules should show up in sonarqube as issues, but never fail a quality gate.

Kind regards,
Michael

2 Likes
49

Hi Lance,

The old deprecated severity retains its original form and 5 values. The solution that is introduced doesn’t rely on customizing the severity but on a dedicated rule priority.

Chris

50

Hi Michael,

We’ve heard of users who use the ‘info’ severity during a grace period when activating new rules. However, this doesn’t seem to be your case.
In your situation, I’m not sure why you need to change the severity since you could accept those issues. I’d be happy to discuss your case in more detail if you have time. I’ll reach out to you.

Chris

1 Like
51

I’m using sonarqube enterprise 10.4.1

If I got the essence of this thread correctly (which I am not sure about), there is no solution yet to the problem that arises from quality gates blocking due to specific rules inside a “Quality Profile” that have a severity assigned that is too high.

According to the hint in the GUI when you mouseover “severity”, severity is now an attribute on the “Quality” level and no longer on the “Rules” level. So if there is one rule contributing to the “Software Quality” “maintainability” that breaks the build pipeline, I can no longer fix this by lowering the severity of the particular rule, but changing the severity of “Software Quality" maintainability".

And there is the point where I got stuck, respectively where questions arise:

  1. How can I change the severity of a “software quality” (which btw. has undesired side effects, because not only the selected rule is impacted but all rules that contribute to the “Software Quality”)?

  2. If 1. is not feasible, do you have suggestions how to work around this issue? I know that I can deactivate rules in the “Quality Profile” and consider this to be the workaround for the time being as long as there is no better solution available.

Edit:
According to the change log, I just found out, that it is still possible to change the “old severity”, which is a data object different from the “severity” that shows up in the rule itselves. Does the “old severity” have any operational impact?

53

Christophe,

I just installed 10.5.1 and I don’t see the original 5 severities in the filter. How do I find Blockers vs Criticals?

image

54

Our company really needs to be able to customize the severity of a rule. We have hundreds of thousands of lines of code across a dozen repositories, and numerous baseline branches that we have to maintain. Naturally, we have a lot of overall sonar violations due to the large amount of code, so our program requirements only require resolving high severity issues. Obviously developers will try to fix lower severity issues when possible, but we only want the high severity ones to fail a build or be absolutely required to be fixed.

From what I understand of your upcoming solution, we still aren’t able to configure the severity of the rules, which will make it hard on us. We need to be able to lower the severity of rules that we don’t find severe enough to warrant failing the build, without having to completely disable them. It’s also important for us to be able to filter on high severity violations to see what remains to be fixed, and would like to clear some of the clutter by lowering the severity of certain rules we have deemed less important.

Basically, I think the fundamental issue here is that someone has now decided what constitutes a high severity issue, but different companies and programs may disagree with that ranking. The current solution appears to take the approach of saying “we’ve decided it’s high severity and we don’t care if you disagree”. I understand things are a little more complicated now that rules can have multiple clean code labels, so perhaps you allow configuring the severity of each clean code label attached to an issue? I strongly believe we need something like we had before to change the criticality of issues, both for UI filtering purposes and for quality gate purposes.

I’m happy to discuss further if you would like any more details! And thanks for continually working to make SonarQube a great product!

2 Likes
56

That does indeed seem to be what is happening, which is in direct contradiction of this from earlier in the thread:

Sonar should be tool to enable us to enforce the rules we want to enforce, that make sense to our organisation - which may be completely different to the rules someone else wants to enforce for their organisation.
More and more unfortunately it seems like the folks at Sonar are trying to impose their version of what is/is not good enough code for all organisations that use their product.

Unfortunately too, it seems to be quite common that some random change is introduced that nobody asked for and nobody likes, which causes an uproar amongst the community and the “stock response” from Sonar is that they will have a think and try to come up with some way around the problem that they introduced in the first place. It seems that no lessons are learned from every time this happens.

I really don’t understand why feedback on major changes isn’t solicted before the change is even started rather than releasing something that can cause massive disruption and will drive existing users away from the product rather than attracting more new users.

1 Like
59

Trying out the 10.6 upgrade, I have to agree with this and other feedback. There have been other breaking changes from Sonar in the past but this one has the largest impact I have seen.

For years, the severity levels (Blocker, Critical, Major, Minor, and Info) and the ability to customize this in Quality Profiles have been instrumental in development workflow, providing a clear and effective way to categorize and prioritize issues. This established system has enabled development teams to focus on the most critical issues first (especially with Blocker vs Critical in New Code), ensuring that high-risk vulnerabilities and significant code flaws are addressed promptly. The removal of these severity levels presents several challenges that could negatively impact operations.

Reduced Clarity and Prioritization:
The five-tier severity system offers a detailed approach to issue categorization, allowing teams to prioritize their efforts based on the severity of the impact. With the reduction of these levels to only 3, it becomes challenging to discern the urgency of issues, potentially leading to critical vulnerabilities being overlooked or delayed in resolution.

Impact on Current Processes:
Since this has been in Sonarqube for a long time, many enterprises have long-established processes and tools built around the existing severity levels and the customization of Quality Profiles to fit the needs of the organization . This breaking change necessitates a significant overhaul of workflows, dashboards, and reporting tools, leading to increased costs and potential disruptions during the transition period.

Training and Adaptation Costs:
Teams are well-versed in the existing severity system. Adapting to a new model requires extensive retraining and adjustment periods, during which productivity may decline. The learning curve associated with this change could hinder teams’ efficiency and delay project timelines.

I don’t believe the change from the established five severity levels (Blocker, Critical, Major, Minor, and Info) to the three new levels (High, Medium, and Low) was necessary to accomplish the Clean As You Code framework that you are endorsing. The Clean As You Code methodology focuses on addressing issues as they are introduced and maintaining a clean codebase over time. This objective can be achieved without reducing the granularity of issue categorization with the current system with Overall vs New Code. The five severity levels provided a more detailed and precise approach, allowing teams customize the process and address the most critical issues with greater clarity and effectiveness, thus better supporting the Clean As You Code initiative.

Regarding the solution you have offered with 10.6. While this new functionality allows for prioritization of issues in custom profiles and quality gates, I don’t believe this feature sufficiently compensates for the change/removal of severity levels and the removal of this customization from the code Quality Profiles. It lacks the intuitive and universally understood categorization provided by the established severity levels. This new prioritized rule in the custom profiles and quality gates requires additional configuration and maintenance, adding complexity to the workflows rather than simplifying them.

I understand that changes are sometimes necessary to drive innovation and improvement. However, I would strongly urge SonarSource to retain the original five severity levels and functionality around this for Issues and Profiles. These levels provide essential granularity and clarity that support efficient issue management and prioritization.

3 Likes
61

You mention elsewhere about “restoring” the feature people use and need, which is customizing the priority of rules to suit their organisations definition of what is/is not important to them.
How does introducing something else actually “restore” the original feature?
I don’t see anyone clamouring for what you have described, only people asking for you to restore a feature that you took away.
Is there any good reason why you can’t just do that? There is no shame in putting your hands up and saying you made a mistake, you will restore feature X rather than implementing Y to “fix what you broke” which doesn’t even do that.

In this case, whilst you may feel that your new solution negates the need to customize priorities, the simple fact is that, as others have stated here, organisations have built processes and agreements around the current way of working and current features and now you are expecting us to re-engage with relevant parties and change processes simply because you decided to remove a very useful and usable existing feature.
Maybe Sonar is a very small organisation and you don’t really appreciate the needs and demands of larger organisations and that we can’t just change things on a whim?

1 Like
63

Hi,

started this thread back in 2023 because i was shocked and frustrated.
In the meantime many others jumped aboard and told you what’s wrong about your concepts.
I sign every word of them.

There’s not a single positive feedback from the community!!
This is a clear indicator that something has gone wrong here.

Your try to fix it is complicating things that wheren’t complicated before :frowning:
It is a sign of true greatness to admit mistakes and put things right - as they were before.
You should revert your changes and bring back the severities and the categories everyone is used to.

Gilbert

1 Like