Analyse de code

1. Présentation

Le serveur Sonar permet d'analyser le code d'un projet en fonction d'un ensemble de règle, et de présenter les résultats via une interface.

Il peut analyser plusieurs langages comme JAVA, PHP, C++…

Le résultat de l'analyse permet de dire si un projet respecte les normes de codage en vigueur, si du code est copier/coller dans plusieurs fichier au lieu d'être mutualisé, etc… Sonar fourni un bilan qualitatif du code du projet.

2. Plugin Intégration continue SourceSup

Ce plugin permet à un projet SourceSup d'utiliser un ensemble d'outils présent sur la forge relatifs à l'intégration continue. Ces outils sont :

  • Jenkins
  • Sonar
  • Nexus

Ils permettent d'avoir un cycle d'intégration continue plus complet, d'analyser le code source des projets et de mettre à disposition des artéfacts sur des dépôts.

Le plugin se compose de 6 onglets :

  • La page d'accueil qui présente les informations générales du plugin, et indique aussi si le projet SourceSup est rattaché à des dépôts Nexus.
  • L'onglet “vue Jenkins”, permet d'afficher l'outil Jenkins dans une iframe, afin de garder l'interface de SourceSup pour garder l'accès au reste de la forge.
  • L'onglet “vue Sonar”, permet d'afficher l'outil Sonar dans une iframe, afin de garder l'interface de SourceSup pour garder l'accès au reste de la forge.
  • L'onglet “vue Nexus”, permet d'afficher l'outil Nexus dans une iframe, afin de garder l'interface de SourceSup pour garder l'accès au reste de la forge.
  • L'onglet “Administration Nexus, visible seulement par les administrateurs du projet, permet de créer des dépôts sur Nexus, attaché au projet SourceSup. Il est possible aussi de les supprimer.
  • L'onglet “Administration Jenkins”, visible seulement par les administrateurs du projet, permet de créer un job sur Jenkins, attaché au projet SourceSup. Il est possible aussi de lancer ce job ainsi que de le supprimer.

2.1. Activation

Ce plugin s'active comme tous les autres dans la partie “Administration” d'un projet, au niveau de l'onglet “outils”. Il suffit de cocher la case “plugin intégration continue” et de valider le formulaire pour que le plugin soit accessible aux membres du projet.

3. Sonar

3.1. Authentification / Accès

Comme pour Jenkins, pas besoin de se créer un compte utilisateur sur Sonar. Une fois authentifié sur SourceSup, l'utilisateur qui accédera à Sonar sera automatiquement authentifié.

3.2. Fonctionnement

Sonar va fonctionner de pair avec Jenkins et le module jenkins-sonar. Celui-ci permet de lancer l'analyse d'un projet par Sonar après le build effectué par Jenkins. Pour analyser un projet avec Sonar, il faudra donc passer par Jenkins. L'utilisateur qui va lancer le build sur Jenkins sera le propriétaire des résultats d'analyse sur Sonar. Un utilisateur accédant à Sonar ne verra que les analyses qu'il a lancé. Libre à lui ensuite d'ajouter des personnes au projet sous Sonar.

Il y a plusieurs façon de lancer une analyse Sonar :

  • Sonar-runner : Cette méthode est celle privilégiée. Pour appeler le sonar-runner, ajouter une nouvelle étape de build “Lancer une analyse Sonar autonome“. Il va falloir préciser quelques options pour utiliser le sonar-runner. Ceci peut être fait directement dans le job dans le champ texte “Propriétés du projet”, ou bien dans un fichier présent dans les sources du projet, dont le chemin sera précisé dans le champ “Chemin vers les propriétés du projet”.
  • projet Mavenisé : ajouter l'action post-build 'Sonar' et lancer le build de votre projet, à la fin du build, maven lancera l'analyse sonar de votre code et vous pourrez voir le résultat en allant sur le serveur sonar.

Sonar Runner

Le sonar-runner se lance en lui précisant des paramètres obligatoires qu'il faut indiquer dans le champ texte “propriétés du projet”:

  • sonar.projectKey=identifiant du projet (exemple le nom unix du projet SourceSup)
  • sonar.projectName=nom du projet
  • sonar.projectVersion=version du projet (ex 1.0)
  • sonar.sources=chemin vers les sources du projet (ex src/main/java)
  • sonar.language=langage du code (ex : php)

d'autres paramètres peuvent être précisés :

  • sonar.tests=chemin vers les sources de tests (ex : src/test/)
  • sonar.ma.propriété=valeur (paramètres additionnels)

Pour pouvoir avoir les droits de voir le résultat de l'analyse Sonar, il est important de lancer le build d'un job à la main une fois. Ensuite le lancement du build peut être lancé automatiquement, après un commit par exemple, ou bien quotidiennement. Si un job a toujours été lancé automatiquement, et que celui-ci demande une analyse Sonar, les résultats ne seront pas visibles tant que le build du job n'aura pas été lancé par un des propriétaires du job.

Analyse C++

Pour le langage C++, deux analyseurs sont installés, cppcheck ainsi que valgrind. Ils peuvent générer des rapports xml exploitable par Sonar. Pour cela rajouter au niveau du job jenkins une commande shell lançant l'exécution de ces outils :

cppcheck --xml --xml-version=1 2> cppcheck-result.xml .
valgrind --xml=yes --xml-file=valgrind-result.xml nom_programme

Puis au niveau des propriétés de lancement du Sonar Runner, rajouter :

sonar.cxx.cppcheck.reportPath=cppcheck-result.xml
sonar.cxx.valgrind.reportPath=valgrind-result.xml

3.3. Mise à jour / Evolution

Sonar sera mis à jour lors des sorties officielles. Un redémarrage du serveur Sonar peut être nécessaire pour la prise en compte des plugins / mises à jour, un mail préviendra les utilisateurs dans ce cas.

Vous pouvez voir tous les plugins disponibles sur le site de sonar : liste officielle des plugins sonar

Pour ajouter un plugin qui ne serait pas installé sur notre plateforme, vous pouvez demander son installation à l'équipe de SourceSup à : support. La demande sera étudiée et le plugin sera installé si son utilité pour la plateforme est avérée.