Nous avons vu, dans le premier post de cette série sur l’analyse de code PL/SQL avec SonarQube, comment j’organise mon environnement d’analyse, avec :
- un dossier C:\SRC\ contenant tous les projets,
- un sous-répertoire dédié au projet,
- différents sous-répertoires dont un ‘..\Source’ avec le code source à analyser.
Dans le cas de notre analyse PL/SQL, ce code se trouvera donc dans un dossier ’C:\SRC\Demo\PLSQL\Source’.
Voyons maintenant comment créer et configurer une analyse SonarQube de ce code, avec Jenkins.
Création du job Jenkins
Je vais présenter ces étapes de manière précise mais sans les détailler ou les commenter car nous avons déjà réalisé cette opération maintes fois.
Je vais bien sûr comment par m’assurer que les services (Windows) Sonar et Jenkins sont bien démarrés. Je lance ensuite Jenkins, et dans la page principale, nous allons activer le lien ‘New Job’.
Dans la page de création du nouveau projet, nous allons sélectionner ‘Build a free-style software project’ (ou l’option correspondante en fonction du langage que vous utilisez avec Jenkins).
Nous entrons le nom du nouveau projet. Notez que vous ne pouvez pas utiliser un nom de job existant.
Une autre manière de procéder serait de choisir l’option ‘Copy existing Job’ afin de récupérer la configuration d’un job existant, et n’avoir à changer que les paramètres qui nous intéressent.
Dans la page de configuration du projet (‘Jenkins > PLSQL_Demo > configuration’ dans notre exemple), nous allons choisir un unique ‘Build step’ (étape d’exécution du job) qui consistera en une analyse Sonar.
Je vais définir dans cette page tous les paramètres nécessaires à l’analyse de notre code PL/SQL avec SonarQube.
Je ne vais pas rentrer dans les détails : nous avons déjà vu par le passé plusieurs exemples de configuration d’analyse. Notons simplement :
- Les paramètres obligatoires : clé et nom de projet, ainsi que sa version. Je pourrai modifier celle-ci facilement depuis Jenkins.
- Le répertoire avec les différents dossiers pour notre projet : ’C:\SRC\Demo\PLSQL’, et au sein de celui-ci, le sous-répertoire avec le code source à analyser.
- Evidemment, la technologie à utiliser, afin que SonarQube connaisse quel plugin ‘language’ utiliser.
La page http://docs.codehaus.org/display/SONAR/SonarQube+Project+Examples sur le site SonarSource vous permettra de récupérer différents exemples de fichiers ‘sonar-project.properties’ pour différentes technologies, et éviter ainsi d’oublier un paramètre important.
Voilà. Nous sauvons la configuration de notre job, nous lançons celui-ci … et il ne nous reste plus qu’à aller regarder les résultats dans SonarQube.
Ce que nous ferons dans notre prochain post.
Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.