Sonar permet de configurer, via une interface graphique, les niveaux de criticité des alertes remontées par PMD et Checkstyle. Ces niveaux peuvent ensuite (après quelques réglages) servir à influencer la santé des builds dans Jenkins - par exemple, l'utilisation de System.out.println provoquera un simple warning, alors que le lancement manuel d'un Throwable fera échouer le build.

Le problème, c'est que chaque outil dispose de ses propres niveaux de criticité, et il n'est pas toujours simple de déterminer leur correspondance d'un outil à l'autre : un réglage "minor" dans Sonar correspond-il à "info" ou "warning" dans PMD ? Et Jenkins le comprendra-t-il comme une alerte de type "low" ou "normal" ?

Après investigation, je vous suis en mesure de vous proposer la table de correspondance ci-dessous :

FindBugs, quant à lui, n'attribue apparemment pas de niveau de criticité à ses alertes ; en tout cas, ils ne sont pas exportés par le permalink de Sonar.

Grâce à ce mapping, j'ai mis en place la stratégie suivante :

• Les alertes corrigées et qui ne doivent jamais réapparaître dans le code sont marquées "Blocking" ou "Critical". La nuance étant que les premières sont orientées "plateforme" (ne pas utiliser com.sun.*, ne pas invoquer le GC...), alors que les secondes relèvent des normes de codage internes (ne pas utiliser printStackTrace, pas de return depuis un block finally...).
• Les alertes qu'on ne peut pas corriger pour des raisons... historiques on va dire, mais qu'on ne souhaite pas voir se multiplier, sont déclarées comme Majeures.
• Les autres alertes sont considérées comme Mineures, et n'influencent pas la santé du build.

Jenkins est ensuite configuré comme suit :

Ainsi, à la moindre réintroduction d'une alerte normalement éliminée, le build échoue ; et si une nouvelle alerte "historique" est ajoutée, le build est considéré comme instable. Le code est donc stabilisé autour d'un plateau acceptable d'alertes, et toute augmentation injustifiée est immédiatement repérée et corrigée.