Help or NFR: Better way to deactivate rules that are active in SonarWay profiles

Using * Developer Edition* Version 8.7 (build 41497)

We are trying to customize / tune the rules that ship with SonarQube to fit our needs.

I have seen google results saying that the way to accomplish this is to create a new profile and copy in the rules for SonarWay into it. For me, this is a non-starter. i don’t want to be tied to doing manual diffs of the rules in my copy compared to updates done by sonarqube automatically whenever we upgrade.

I am happy to take advantage of extending the built in profile, and we do that in several cases to change severity or some kind of threshold (like line length or complexity). I don’t see why I can’t just deactivate an inherited rule, as it seems like it would solve my problem without the huge downside of manually copying into a new profile. FWIW, right now, I am forced to do things like setting a threshold extremely high as a workaround to disabling it, but I would prefer to simply disable it (which I assume is also better for performance).

Is there a way to disable a rule by brute force via the DB? I realize it might get undone on upgrade, but IMO this it far less work to re-apply DB changes after each release than trying to do a manual compare of rule set changes if I create a copy.

You can compare rules directly in the UI, if you weren’t aware. Cleverly you can activate rules right from that interface.

Yes, it’s still rather manual.

The thinking is that a parent profile is a starting point; the minimum acceptable standard and on top of that you would add rules.

Don’t touch the database. And, I’m pretty sure it would get undone at every restart of your SonarQube server.

For what it’s worth we’ve thought about it and the topic isn’t dead entirely. You can add to this topic and I’ll pass your feedback on through the mechanisms we have internally. :slight_smile:

Colin,

I really appreciate your prompt response. I did not realize that there was a compare function in the UI, which certainly does bring down the barrier to having a manually copied profile.

That said, I hope that there is further discussions and consideration of allowing a profile to deactivate an inherited rule. I think it has some (probably small) benefits in reducing number of rule entries in the DB (for copies) or performance of running the scans (for extensions that tweak rule configuration to make them in effect deactivated).

I understand and agree with the viewpoint that the SonarWay profiles should the the starting point for end user Quality Profiles. However, I don’t share the mindset that the particular rules that happen to be in the SonarWay profile must be considered the minimal accepted set as a quality baseline.

In general, the quality of the code is measured and monitored by the gates, not the profile. The profile is simply a way to define how to measure quality not whether the code is of sufficient quality.

But besides that theoretical point, on a practical basis, people want to use the tool to help them to establish and maintain code quality, given the codebase they have today. There are a number of practical reasons for us (and probably others) why certain rules that make sense in general cannot be reasonably addressed at this time, and having sonarqube detect violations of those rules just makes it harder to get an accurate assessment of whether a PR is of sufficient quality.to be merged. It forces us to lower our thresholds in our quality gate (which is not good for several reasons) or to allow PRs to be merged that do not pass the quality gate (which is also not desirable)…

Stated another way: I consider the SonarWay quality profiles to be the community/industry “best practice” guidelines. The design today already allows an organization to edit inherited rules to make them less effective (e.g. change something to an Info level), so it seems there is already a tacit acknowledgement that not every rule in the SonarWay profile is appropriate for all codebases. Allowing an organization to deactivate an inherited rule is simply making this tacit acknowledgment explicit.

I don’t either. I only meant that in general, this was the use-case considered for inheritance of Quality Profiles (minimum baseline, whatever it is, + more)

It’s an interesting percecption we’re kind of aware of – but doesn’t reflect exactly what this Quality Profile was born to represent. It’s meant to represent non-controversial rules with few false-positives to get started using our products. From the docs…

The Sonar way Quality Profiles are a good starting-point as you begin analyzing code, and they start out as the default Quality Profiles for each language. That being said, we recommend that you Copy this profile and begin to fine-tune the contents. Why?

  • Default Quality Profiles are not editable, so you won’t be able to customize the Sonar way to your needs
  • The Sonar way becomes a baseline against which you can track your own Quality Profiles
  • The Sonar way may be updated over time to adjust which rules are included and adjust rule severities.

A fair point.

Thanks for the feedback.

With this mindset, I see even less reason to not allow inherited rules to be deactivated. It is far easier to get started by extending the built in profiles and tweaking them than making and maintaining a copy.

Also, to address the 3 specific bullets you cited:

  • Default Quality Profiles are not editable, so you won’t be able to customize the Sonar way to your needs
    → No different for extended vs copied
  • The Sonar way becomes a baseline against which you can track your own Quality Profiles
    → Easily done for extended profiles (inheritance = overridden)
  • The Sonar way may be updated over time to adjust which rules are included and adjust rule severities.
    → Huge plus for extended, as in general, I want my profile to get those adjustments “for free”