« Retour

SonarQube met son grain de sel dans Gitlab !

La galaxie SonarQube

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.

Problème initial : trop ou trop peu de données qualimétriques ?

Entre surcharge informationnelle...

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 ?

... et isolement des informations

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.

Comprendre les lancements d’analyse SonarQube

Il faut d’abord savoir que SonarQube dispose de 3 modes de lancement :

  • Analysis : il s’agit du mode de lancement par défaut de SonarQube. Tous les fichiers sont analysés et SonarQube crée ou met à jour un projet dans sa base de données.
  • Preview : tous les fichiers sont également analysés mais les résultats ne sont pas stockée dans la base de données.
  • Incremental : seul le fichier courant ou les derniers fichiers modifiés sont analysés. Il s’agit du mode de lancement par défaut de SonarLint.
    Source : https://blog.sonarsource.com/analysis-vs-preview-vs-incremental-preview-in-sonarqube/

Ce sont sur ces modes de lancement que nous allons nous appuyer pour différencier les analyses des branches features et master :

  • Pour la branche master, nous allons continuer d’utiliser le mode analysis, et stocker les résultats dans la base de données.
  • Pour les branches temporaires, nous allons basculer sur le mode preview, ce qui va nous permettre de générer le rapport et de le visionner… sur Gitlab !

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.

Mise en pratique

Récupération du plugin

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.

Configuration de Gitlab

  1. Créer un compte Gitlab avec comme nom SonarQube
  2. Se connecter sur Gitlab en tant qu’administrateur et attribuer à l’utilisateur SonarQube le profil « Développeur » dans les groupes contenant les projets à analyser
  3. Se connecter sur Gitlab avec l’utilisateur SonarQube et générer un token sur la page http://urldegitlab/profile/personal_access_tokens

Configuration de SonarQube

  1. Se connecter sur SonarQube en tant qu’administrateur
  2. Dans « Configuration », se rendre dans le tout nouvel onglet « Gitlab »
  3. Dans le formulaire qui s’ouvre, renseigner le token
  4. Remplir les champs « Global template » et « Inline template » en adaptant les templates proposés ici : https://gitlab.talanlabs.com/gabriel-allaigre/sonar-gitlab-plugin#examples

Configuration du projet à analyser

  1. Sur Gitlab, récupérer l’id du projet souhaité, qui se trouve dans les Settings du projet.
  2. Sur SonarQube, revenir à l’écran des projets, cliquer sur le projet concerné, puis sur « Configuration » > « Paramètres projet » > « Gitlab »
  3. Dans le formulaire qui s’affiche, renseigner l’id du projet récupéré dans Gitlab et, éventuellement, adapter les barrières qualité du projet
  4. Pour être analysé par SonarQube, un projet doit contenir un fichier sonar-project.properties. Ajouter les deux lignes suivantes à ce fichier :
     sonar.analysis.mode=${MODE_ANALYSE}
     ${GITLAB_CONFIG}

    A noter : les variables ${MODE_ANALYSE} et ${GITLAB_CONFIG} seront remplacées au moment du build Jenkins.

Configuration du job Jenkins

  1. Sur Jenkins, créer un build et ajuster les actions déclenchant le build ; ici, à chaque fois qu’un changement a lieu sur Gitlab
  2. Lors de l’étape de récupération des sources, prendre soin de ne cibler aucune branche en particulier.
  3. Ajouter une étape « Exécuter un script shell » avec le script suivant :
     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
  4. Ajouter l’étape de lancement de l’analyse SonarQube.

Intégrer l’analyse de code à tous les niveaux

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 !

Vous aimerez peut-être...

Sondez votre code avec SonarQube

La qualité de code en direct avec SonarLint !

Un avis ? Un commentaire ?

Cet espace est pour vous.



1 commentaire(s)

  • Je viens de découvrir ce blog et je trouve les articles pertinents et de très bonne qualité. Continuez ce travail, j'ai hâte de lire les prochains articles !