Un avis ? Un commentaire ?
Cet espace est pour vous.
Attention, cet article est ancien ! Certaines parties sont peut-être inadaptées à votre stack actuelle. Pour découvrir nos nouveaux article sur le test et la qualité logicielle, nous vous conseillons de consulter la page d’accueil de notre blog. Amusez-vous bien !
Dans de précédents articles, nous avons présenté SonarQube, son interface ainsi que son intégration avec Jenkins, et SonarLint, son acolyte qui permet aux développeurs de vérifier la qualité de leur code avant de le commiter. Aujourd’hui, nous voulons affiner encore les choses, et différencier l’analyse des branches features et master.
Cet article présente un applicatif open-source, disponible en l’état et sans garantie. Il est de la responsabilité du SI de vérifier qu’il est conforme à sa politique de sécurité d’une part, et de respecter sa licence d’autre part. Merci à Gabriel Allaigre, de Talanlabs, pour le plugin Sonar-Gitlab !
La procédure suivante met en oeuvre SonarQube, Gitlab et Jenkins en environnement Linux.
Dans un projet donné, il arrive que chaque branche (de feature ou même de bug) fasse l’objet d’une analyse SonarQube à chaque fois que du nouveau code est poussé dessus. Les résultats de cette analyse sont alors stockés dans la base de données et affichés dans l’interface.
Le problème, c’est qu’il en résulte rapidement une liste interminable de « projets » SonarQube qui n’en sont pas ; ce ne sont que des branches ! Ces résultats sont conservés indéfiniment alors qu’ils perdent leur intérêt dès que les branches sont fusionnées.
Comment éviter ce bruit tout en conservant le feedback de SonarQube ?
Par ailleurs, il est assez courant d’entendre des témoignages de ce type : « Nous avons installé SonarQube et des analyses sont régulièrement lancées sur nos projets, mais en pratique on ne les regarde pas souvent. » Effectivement : SonarQube est simple à installer, simple à configurer et simple à utiliser. Le plus difficile est de l’intégrer pleinement aux modes de travail des équipes.
Le plugin présenté ici vise à résoudre le premier problème, tout en apportant un élément de solution au second.
Il faut d’abord savoir que SonarQube dispose de 3 modes de lancement :
Ce sont sur ces modes de lancement que nous allons nous appuyer pour différencier les analyses des branches features et master :
L’idée est de permettre à un utilisateur Gitlab dédié (que l’on nommera tout simplement SonarQube) de commenter les commits en indiquant les mauvaises pratiques détectées dans les portions de nouveau code.
La dernière version stable du plugin Sonar-Gitlab est disponible depuis le centre de mise à jour de SonarQube, vous pouvez l’y installer directement.
Si vous souhaitez utiliser la toute dernière version du plugin, vous devrez récupérer le projet Sonar Gitlab Plugin sur la page Github du projet, placer le jar dans le répertoire « plugins » de Sonarqube (SONARQUBE_HOME/extensions/plugins) puis redémarrer SonarQube.
sonar.analysis.mode=${MODE_ANALYSE}
${GITLAB_CONFIG}
A noter : les variables ${MODE_ANALYSE} et ${GITLAB_CONFIG} seront remplacées au moment du build Jenkins.
ID_PROJET="124" # id du projet, à récupérer dans Gitlab
URL_SONARQUBE="http://urldesonarqube"
SHA_DERNIER_COMMIT=$GIT_COMMIT
if ["$GIT_BRANCH" = "origin/master" ];
then
echo "Nous sommes sur la branche master. Les résultats de cette analyse seront enregistrés dans la base de données de SonarQube."
sed -i "s/${MODE_ANALYSE}/publish/g" sonar-project.properties # on suppose que ce fichier est à la racine du projet. Adapter le chemin si besoin.
sed -i "s/${GITLAB_CONFIG}//g" sonar-project.properties
else
echo "Nous sommes sur une autre branche que master. Les résultats de cette analyse seront enregistrés dans les commentaires de l'utilisateur SonarQube dans Gitlab."
sed -i "s/${MODE_ANALYSE}/preview/g" sonar-project.properties
# Configuration Gitlab
sed -i "s/${GITLAB_CONFIG}/sonar.gitlab.commit_sha=${CI_BUILD_REF}nsonar.gitlab.ref_name=${CI_BUILD_REF_NAME}nsonar.gitlab.project_id=${ID_PROJET}nsonar.host.url=${URL_SONARQUBE}nsonar.issuesReport.console.enable=true/g" sonar-project.properties
sed -i "s/${CI_BUILD_REF}/$SHA_DERNIER_COMMIT/g" sonar-project.properties
sed -i "s/${CI_BUILD_REF_NAME}/$SHA_DERNIER_COMMIT/g" sonar-project.properties
fi
Récapitulons. Désormais, à chaque changement dans le dépôt Gitlab, un build Jenkins sera lancé. Si c’est la branche master qui est concernée, un rapport sera enregistré dans la base de données de SonarQube ; sinon, des commentaires seront postés sur le commit pour indiquer d’éventuelles mauvaises pratiques dans le nouveau code introduit.
Bonnes analyses !
Cet espace est pour vous.