{"id":126,"date":"2011-12-28T17:38:49","date_gmt":"2011-12-28T16:38:49","guid":{"rendered":"http:\/\/dev.qualilogy.com\/fr\/?p=126"},"modified":"2013-01-04T17:39:33","modified_gmt":"2013-01-04T16:39:33","slug":"sonar-analyse-cobol-avec-jenkins","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/sonar-analyse-cobol-avec-jenkins\/","title":{"rendered":"Sonar – Analyse Cobol avec Jenkins"},"content":{"rendered":"

Nous avons vu dans le post pr\u00e9c\u00e9dent<\/a> comment installer le plugin Sonar pour Jenkins. Il est temps maintenant d’effectuer notre premi\u00e8re analyse depuis Jenkins. Celle-ci portera sur le code source Cobol d\u00e9j\u00e0 utilis\u00e9 lors de notre premi\u00e8re analyse avec Sonar<\/a> et le Java Runner. <\/p>\n

\"\"<\/a>Pour cela, nous allons cr\u00e9er un projet, depuis la page principale de Jenkins.<\/p>\n

Dans la page de cr\u00e9ation, nous entrons un nom de projet et s\u00e9lectionnons la premi\u00e8re option: \"\"<\/a><\/p>\n

Ceci nous ouvre la page de configuration de ce projet, dans laquelle il nous suffit d’indiquer que nous souhaitons effectuer une analyse Sonar:\"\"<\/a><\/p>\n

Il nous reste simplement \u00e0 indiquer notre fichier de configuration pour cette analyse, le m\u00eame que d\u00e9j\u00e0 utilis\u00e9 pour notre premi\u00e8re analyse avec Sonar<\/a>, c’est-\u00e0-dire : C:\\Soft\\Sonar\\sonar-runner-1.1\\Projects\\sonar-project.properties<\/strong> :<\/p>\n

\"\"<\/a>Mais auparavant, nous allons sp\u00e9cifier dans ce fichier une nouvelle version pour notre analyse: sonar.projectVersion=1.1<\/strong>.<\/p>\n

\"\"<\/a>N’oubliez pas de sauvegarder les param\u00e8tres de votre projet.<\/p>\n

Avant de lancer celui-ci.\"\"<\/a><\/p>\n

\"\"<\/a>Pendant que le projet s’ex\u00e9cute…<\/p>\n

 <\/p>\n

\"\"<\/a>Nous pouvons regarder le log d’analyse:<\/p>\n

\"\"<\/a>Puis dans Sonar, le r\u00e9sultat de cette analyse, avec la version indiqu\u00e9e dans notre fichier de configuration:\"\"<\/a><\/p>\n

Nous avons vu comment contourner deux inconv\u00e9nients du Java Runner (que nous utilisons par manque de pratique de la syntaxe Maven) :<\/p>\n

    \n
  1. Un fichier unique de configuration d’analyse : Jenkins nous permet de sp\u00e9cifier un fichier distinct pour chaque analyse Sonar.<\/li>\n
  2. Un log beaucoup plus pratique et convivial chaque fois que nous lancerons une de nos analyses Sonar.<\/li>\n<\/ol>\n

    Ceci nous permet une grande souplesse d’utilisation, notamment dans l’organisation de notre environnement d’analyse. Nous allons voir deux exemples.<\/p>\n

    Je vais commencer par renommer le fichier sonar-project.properties en Myproject.properties<\/strong>, dans le r\u00e9pertoire ..\\sonar-runner-1.1\\Projects<\/strong>. Je modifie \u00e9galement la version d’analyse (sonar.projectVersion=1.2<\/strong>) dans ce fichier, simplement afin de v\u00e9rifier que celui-ci est bien pris en compte.<\/p>\n

    Je vais ensuite indiquer ce nouveau fichier dans la configuration de mon projet Jenkins avant de lancer celui-ci \u00e0 nouveau…\"\"<\/a>\"\"<\/a>Et de v\u00e9rifier le r\u00e9sultat dans Sonar : une nouvelle version 1.2 appara\u00eet effectivement. Ceci signifie que je peux utiliser un espace ‘Projet’ avec autant de fichiers de configurations que j’ai d’applications \u00e0 analyser.<\/p>\n

     <\/p>\n

    Un autre type d’organisation consiste \u00e0 d\u00e9dier un disque dur \u00e0 mon environnement d’analyse, avec un dossier par application, au sein duquel je placerai \u00e0 la fois le code source applicatif, mais \u00e9galement tout fichier de configuration d’analyse. Dans ce second exemple, je vais :<\/p>\n