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 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.
Inheritance was designed to share a common baseline for quality and security across various projects. With this perspective, you can currently define a minimal set of rules that the teams can extend but that they can’t reduce.
We monitor requests on the topic and also track feedback in a dedicated Portal card.
In your case, since you are trying to have some profiles at the company level, do you plan to fully delegate the possibility to reduce this baseline to the teams?
we do already delegate responsibility to the teams, because we (try to) practice a DevOps approach, where each team’s devs are fully responsible for their own build pipeline, which includes any static analysis solutions. We do recommend and document standard practices and pipelines, but projects might have very specific needs.
Forcing teams onto a baseline ruleset might lead to
A) for high number of rules - teams not running sonar at all, because they do not want to be bombarded with issues that they can do very little about (because they might use legacy frameworks that force certain choices on them like inheritance depth) or
B) for low number of rules - having too few rules and teams not adding more rules on their own because that is additional work
In addition, we currently only create standard profiles for the most important languages. This is why we currently allow all teams to create quality profiles on their own if necessary. The problem with that is of course, that now all teams have permission to change even the standard company profiles, but we back up those profiles to make sure we can revert unintended changes.
Ideally, teams could define “project level” profiles that extend company wide profiles, and we could globally enable deactivation of rules in extended profiles. Then once in a while we could compare project level profiles with the standard profile to improve our standard profile.
Thanks for your explanations.
If I understand it well, you seem to use the parent quality profiles as a recommendation that the teams can fully override, more than as a baseline for a standard of quality.
As a side note, you also have the possibility to create quality profiles and delegate them to the teams.