Start breaking the CI job when the SonarQube quality gate fails

Development
1

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 SonarCloud).

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 SonarCloud
  • Add a quality gate of failing the CI build when there’s > 0 blocker issues on new code. See SonarCloud
  • Make the modification to our jenkins pipeline to fail the job (this means Breaking the SonarQube Analysis with Jenkins Pipelines ).

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 Java static code analysis | junit 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

2

+1

Thanks,
Marius

3

+1

Thanks

4

+1

For those who don’t know about it: there is an IDE extension called sonarlint which works well and will show you those broken rules before you commit.

5

+1

Thanks,
Alex

6

I’ve now set it up on sonarcloud and in our Jenkins pipeline ([Misc] Add a step to check the Sonarqube quality gate and fail the bu… · xwiki/xwiki-jenkins-pipeline@0bbf801 · GitHub).

Let’s see if it works at the next build!