SonarQube en service Windows avec Jenkins sous Tomcat

SonarQube2 Nous avons vu lors de notre dernier post comment migrer SonarQube en tant que service Windows. Nous avons en fait effectué une nouvelle installation, sans perdre notre repository, constitué avec notre version de SonarQube sous Tomcat. Nous avons pu vérifier que nos projets, les résultats d’analyses précédents, mais également toute la configuration existante (plugins, Quality Profiles, etc.) étaient bien présents.

Bien. Mais qu’en est-il de Jenkins ? Notre Jenkins sous Tomcat travaillait avec la version Tomcat de SonarQube. Nous devons maintenant lui indiquer de travailler avec notre service Windows de SonarQube.

Comment procéder ? Voici les étapes que j’ai suivies. 

 

Désinstaller SonarQube sous Tomcat

La première étape a consisté à supprimer la webapps SonarQube sous Tomcat. Pour cela, j’ai tout simplement :

  1. Ouvert le répertoire de localisation de cette dernière – C:\Program Files (x86)\Apache Software Foundation\Tomcat 7.0\webapps – sur mon portable.
  2.  Supprimer le fichier ‘Sonar.war’ et le sous-répertoire ‘Sonar’ dans ce dossier.

Evidemment, vous aurez pris soin de stopper le service Windows de Tomcat au préalable.

Lancer une analyse avec Jenkins sous Tomcat

Nous allons maintenant tenter une analyse avec Jenkins. Cette étape n’est pas obligatoire, et je dirais même n’a pas de sens : notre installation actuelle de Jenkins ne connaît que la version Tomcat de SonarQube, que nous venons justement de supprimer.

Mais comme nous l’avons vu dans notre post précédent, SonarQube s’appuie complètement sur son propre repository, c’est-à-dire son propre schéma de base de données, et notre Jenkins actuel sait comment alimenter celui-ci.

Je vais donc :

StartTomcat

  • Démarrer le service Windows Tomcat.
  • Lancer une analyse existante sous Jenkins, en prenant au préalable le soin de modifier la version de projet pour cette analyse.

 

JenkinsSonarConf Pour cela, cliquez simplement sur le menu déroulant qui apparaît à droite du lien / du nom de projet, et dans ce menu, sélectionnez ‘Configure’.

J’ai choisi ici une application (en fait différentes applications) de code ABAP (SAP), et dans le fenêtre suivante, de configuration de mon analyse sous Jenkins, je vais modifier la version de projet afin d’incrémenter celle-ci en version 2.0.

N’oubliez pas de sauvegarder ce nouveau paramètre avant de lancer à nouveau cette analyse.

SonarProjectPropVersion

Celle-ci exécutée montre bien la version 2.0, depuis le portail de SonarQube en service Windows…

SonarAbapV2

… alors même que Jenkins pointe toujours sur la version Tomcat de SonarQube :

SonarJenkinsV2

Encore une fois, rien d’anormal à cela, puisque les résultats d’analyse sont toujours sauvegardées dans le repository de SonarQube, le schéma ‘Sonar’ en base de données (Oracle dans mon cas).

Configurer Jenkins avec le nouveau SonarQube en service Windows

JenkinsConfSystemDans la fenêtre de gestion de la configuration Jenkins (‘Manage Jenkins’), nous choisissons le menu ‘Configure System’.

Dans la fenêtre suivante, nous allons rechercher la partie consacrée à la configuration de Sonar dans Jenkins, et activer le bouton ‘Advanced…’.

JenkinsSonarConfigEt dans la page de configuration de SonarQube, indiquer l’url du tableau de bord (celle-ci a changé suite à l’installation de SonarQube en service Windows).

JenkinsSonarUrl

Remarque importante : vous pouvez constater que j’ai indiqué la nouvelle url de SonarQube sans le slash (ou barre oblique) final. Cela fonctionnera sans problème mais je vous suggère de normaliser cette adresse url en ajoutant ce slash à la fin.

N’oubliez pas de sauvegarder ce changement de paramètre avec le bouton ‘Save’ en fin de page.

Jenkins s’appuie sur le SonarQube Runner pour fonctionner. Nous avons vu l’installation de ce dernier dans ce post ‘Installer SonarQube – SonarQube Runner‘. A cette occasion, nous avons configuré le SonarQube Runner avec tous les paramètres nécessaires à son bon fonctionnement, indiqués dans le fichier ‘sonar-runner.properties’.

Dans ce fichier, nous allons indiquer mainteant la nouvelle url du portail SonarQube, tel que précédemment sous Jenkins.

SonarQubeSonarUrlOk

Notez bien à nouveau la présence du slash en fin d’url.

Lancez à nouveau l’analyse : le log d’analyse sous Jenkins (ou ‘Console Output’) doit vous indiquer le message suivant :

ANALYSIS SUCCESSFUL, you can browse http://localhost:9000

Remarque : en début de log d’analyse, le ‘server’ SonarQube comporte bien un slash à la fin de l’url mais ce message final apparaît toujours sans celui-ci.

En cliquant sur ce lien, vous devez accéder au portail SonarQube et voir le résultat de votre analyse. Evidemment, n’oubliez pas de lancer le service Windows correspondant auparavant.

Erreurs possibles

J’ai expérimenté différentes combinaisons d’installation de SonarQube et Jenkins, sous Tomcat ou en service(s) Windows, et différentes configurations. J’ai rencontré certaines erreurs, et je vais en lister deux ici, qui à mon avis se rencontrerons assez fréquemment. Et vous allez comprendre pourquoi j’insiste sur la normalisation du slash à la fin de l’url du portail SonarQube.

Si vous rencontrez le message d’erreur suivant :

The current batch process and the configured remote server do not share the same DB configuration.
 - Batch side: jdbc:oracle:thin:@localhost:1521/JPORA11 (sonar / *****) 
 - Server side: check the configuration at http://localhost:9000/system

Vérifiez que vous avez indiqué exactement la même url dans la configuration de SonarQube sous Jenkins et dans le fichier ‘sonar-runner.properties’ du SonarQube Runner.

Si vous rencontrez le message d’erreur suivant :

Exception in thread "main" java.lang.IllegalStateException: Fail to request server version
 at org.sonar.runner.Bootstrapper.getServerVersion(Bootstrapper.java:73)
...
caused by: java.net.ConnectException: Connection refused: connect
 at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
...
 at java.net.URLConnection.getContent(URLConnection.java:748)
 at org.sonar.runner.Bootstrapper.remoteContent(Bootstrapper.java:125)
 at org.sonar.runner.Bootstrapper.getServerVersion(Bootstrapper.java:71)
 ... 4 more
Finished: SUCCESS

Commencez d’abord par vérifier que vous avez bien démarré le service Windows de SonarQube. Je pense que cette erreur sera la plus fréquente (en tout cas dans mon expérience d’étourdi chronique).

Vérifiez à nouveau les urls et plus particulièrement la présence du backslash à la fin de celle-ci dans le fichier ‘sonar-runner.properties’ de configuration du SonarQube Runner.

SonarQubeSonarUrl

Celui-ci n’accepte pas de travailler avec une url sans le slash final. Mais de toutes façons, si vous avez suivi la procédure indiquée dans ce post et que vous rencontrez un message d’erreur, commencez par vérifier cette url à la fois sous Jenkins et sous SonarQube Runner. J’ai également rencontré ce cas et il peut s’avérer ardu ou long à investiguer avant de penser à rajouter cette barre oblique finale.

Le prochain post sera consacré à l’installation de Jenkins en service Windows. Et finalement nous débarrasser de ce bon vieux Tomcat.

A la semaine prochaine.

Ce article est également disponible en Leer este articulo en castellano et Read that post in english.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *