we are currently migrating our company’s teams / projects from an old free version to a paid SonarQube 8.9 Dev Edition. We happily noticed the extend functionality of quality profiles (new for us) which we thought would allow us to create a company wide profile standard for our main languages, but then realized that an extended profile cannot deactivate rules.
Sadly this actually makes that functionality useless for us, because the only usecase for extending profiles for us is to allow single projects to deactivate rules to create their own custom rulesets (and maybe somtimes change a priority, but that will probably not happen a lot).
Here are some workarounds, which sadly don’t work for us:
Define the smallest set of rules as standard profile and let projects add rules instead of deactivating them. This doesn’t work because a lot of projects would not bother to add rules or have no reason to do so. We would end up with most projects just using the minimal set and therefore missing a ton of rules.
Let projects lower priority instead of deactivating rules. This doesn’t work for us, because we want to allow our developers to focus on the important things and the constant visual clutter coming from rules that were “deactivated” by priority is still there and still annoying. This also messes up statistics and means that we effectively can no longer differentiate between actual info rules and “deactivated” rules.
Tell projects to deactivate rules in the individual project configuration by multiple-criteria exclusion. This doesn’t work for us, because
- we want to continiously improve our standard rulesets. This means for each rule we need to have an easy way of seeing which projects disabled the rules. The rule itself has the perfect UI for that, the project settings on the other hand are messy and complicated.
- we wan’t projects, when they deactivate a rule, to write their reasons into the extended rule description. Deactivating rules in the projects settings would mean we no longer have an easy way to find the disabled rules and check if reasons were given for disabling.
- the multi-criteria exclusion settings UI is much more convoluted than we would like. We would have to explain to every project how to use it. The rule pages itself with an option to deactivate on the other hand would be basically self-explanatory.
- the features that we get for Quality profiles (like easy backup and restore of only a single ruleset) are missing.
I have seen in this post (Extended Quality profile has no option to deactivate rules - #6 by ganncamp) that current state of rule disabling not being available is intentional, it would be very interesting for me to understand what the intention behind not allowing this is.
I hope i could explain my motivation for the suggestion to allow extended profiles to disable rules (or have a global option toggle that allows this) and why using workarounds is not feasable for us. Being able to properly use extended profiles would be very useful for all our projects.