Hi devs,
I’d like to propose that we start using SonarQube more to complement our checkstyle usage since SonarQube provides a lot more checks and much better and more interesting in general.
One nice thing is that we can add a new quality gate rule so that it applies only to new code. The old issues are still reported in SonarQube’s UI but they won’t break the quality gate.
The idea would be to start small with the blocker rules defined by Sonar by default (see https://sonarcloud.io/organizations/xwiki/rules?activation=true&qprofile=AXkPFq9x82EFwtQpnbXw&severities=BLOCKER&types=BUG).
So to get started I propose to:
- Use Sonar’s default rules (i.e. create an XWiki quality rule set that inherits from Sonarqube’s, so that we can add changes in the future while still benefit from new rules added by SonarQube). See https://sonarcloud.io/organizations/xwiki/quality_profiles?language=java
- Add a quality gate of failing the CI build when there’s > 0 blocker issues on new code. See https://sonarcloud.io/organizations/xwiki/quality_gates/show/43654
- Make the modification to our jenkins pipeline to fail the job (this means SonarSource Blog ).
Then, anyone would be free to suggest at any time to set some rules as Blocker. For example, if we agree with this I’ll propose to add Rules explorer as blocker (this is just an example, we can add a lot more).
Ofc, we should also fix the blocker issues on existing code, as a best effort and whenever we can.
WDYT?
Thanks