Grails est un framework d’application web dynamique open-source construit avec Groovy et beaucoup d’autres frameworks Java open-source bien établis tel que Spring ou Hibernate.

Jenkins fournit un excellent support pour les builds Grails. Premièrement, vous devez installer le plugin Grails.Une fois que vous l’avez installé et redémarré Jenkins, vous devrez fournir au moins une version de Grails pour Jenkins dans la section Grails de l’écran de configuration du système (voir la figure Figure 5.49, “Ajouter une installation Grails à Jenkins”).

Figure 5.49. Ajouter une installation Grails à Jenkins

Maintenant vous pouvez configurer une tâche de build Freestyle pour construire un projet Grails. Le plugin Grails ajoute l’étape de build « Build with Grails », que vous pouvez utiliser pour construire un application Grails (voir la figure Figure 5.50, “Configurer une étape de build Grails”). Ici, vous fournissez la target Grails, ou les targets, que vous voulez exécuter. A la différence de la ligne de commande, vous pouvez exécuter plusieurs targets dans la même ligne de commande. Cependant, si vous souhaitez passer des arguments sur une target particulier, vous devez placer la target et ses arguments entre guillement. Dans la Figure 5.50, “Configurer une étape de build Grails”, par exemple, nous lançons grails clean, suivi de grails test-app -unit -non-interactive. ur que cela fonctionne correctement, il faut mettre les options de la seconde commande entre guillemet, ce qui nous donne grails clean "test-app -unit -non-interactive".

Figure 5.50. Configurer une étape de build Grails

L’étape de build Grails peut prendre beaucoup de paramètres optionnels. Par exemple, Grails est minutieux avec les versions — si vous projet a été créé avec une version plus ancienne, Grails vous demandera de la mettre à jour. Pour jouer la sécurité, par exemple, vous pourriez cocher la case à cocher Forge Upgrade, qui assure de lancer un grails upgrade --non-interactive avant de démarrer les targets principales.

Vous pouvez aussi configurer le port du serveur (utile si vous exécutez des tests web), et n’importe quel autre propriété que vous voulez passer au build.

Rédigé par René Groeschke

En comparaison des outils de build anciens Ant et Maven, Gradleest un nouvel outil de build open source pour la machine virtuel Java. Les scripts de build pour Gradle sont construits dans un Domain Specific Langage (DSL) basé sur Groovy. Gradle implémente la convention avant la configuration, permet un accès direct aux tasks Ant, et utilise une gestion des dépendances déclarative comme Maven La nature concise du scripting Groovy vous permet d’écrire des scripts de build plus expressif avec très peu de code, au prix de la perte du support d’un IDE qui existe pour les outils établis tel que Ant et Maven.

Il y a deux manières différentes de lancer des builds Gradle avec Jenkins. Vous pouvez utiliser soit le plugin Gradle pour Jenkins soit la fonctionnalité d’enveloppement (wrapper) de Gradle.

5.10.2.1. Le plugin Gradle de Jenkins

Vous pouvez installer le plugin Gradle avec la façon habituel — il suffit d’aller sur l’écran du gestionnaire de plugin et de sélectionner le plugin Gradle. Cliquez sur installer et redémarrez l'instance de Jenkins.

Une fois que Jenkins a redémarré, il vous faut configurer vous nouveau plugin Gradle. Vous trouverez maintenant une nouvelle section Gradle dans la page de configuration du système. Ici, il vous faudra ajouter une installation de Gradle que vous souhaitez utiliser. Le processus est similaire que pour les autres installations d’outil utilisé. Premièrement, cliquez sur le bouton Ajouter Gradle pour ajouter une nouvelle installation Gradle, et entrez un nom approprié (voir la figure Figure 5.51, “Configurer le plugin Gradle”). Si Gradle a déjà été installé sur votre serveur de build, vous pouvez pointer vers le répertoire local de Gradle. Sinon, vous pouvez utiliser la fonctionnalité « Installer automatiquement » pour télécharger une installation de Gradle, sous le forme d’un fichier ZIP ou GZipped TAR, directement à partir d’une URL. Vous pouvez utiliser une URL publique (voir http://gradle.org/downloads.html), ou vous pourriez préférer de mettre ces installations disponibles sur le serveur local uniquement.

Figure 5.51. Configurer le plugin Gradle

Vous utilisez typiquement des tâches de build Freestyle pour configurer vos builds Gradle. Lorsque vous ajouter une étape de build a une tâche de build Freestyle, vous aurez maintenant une nouvelle option appelée « Invoque Gradle script », qui vous permet d’ajouter des options spécifiques de Gradle à votre tâche de build.

Par exemple, voici un script Gradle très simple. C’est un projet simple Java qui utilise une structure de répertoire Maven et un gestionnaire de dépôt Maven. Il y a une tâche paramétrable, appelée uploadArchives, pour déployer l’archive générée vers un gestionnaire local de dépôt d’entreprise :

apply plugin:'java'
apply plugin:'maven'

version='1.0-SNAPSHOT'
group = "org.acme"

repositories{
  mavenCentral()
    mavenRepo urls: 'http://build.server/nexus/content/repositories/public'
}

dependencies{
  testCompile "junit:junit:4.8.2"
}

uploadArchives {
  repositories.mavenDeployer {
    configuration = configurations.archives
      repository(url: "http://build.server/nexus/content/repositories/snapshots") {
        authentication(userName: "admin", password: "password")
     }
  }
}

Dans la Figure 5.52, “Configurer une tâche de build Gradle”, nous utilisons l’instance « Gradle-0.9RC2 » qui vient d’être configurée pour démarrer un build Gradle. Dans ce cas, nous souhaitons démarrer des tests JUnit et télécharger les artefacts de build vers notre dépôt local Maven. De plus, nous configurons notre tâche pour collecter les résultats de test depuis **/build/test-results, le répertoire par défaut stockant les résultats de test avec Gradle.

5.10.2.2. Les builds incrémentaux

Lorsqu’on lance une tâche de build Gradle avec des sources non modifiées, Gradle lance ses builds incrémentaux. Si la sortie d’une tâche Gradle est toujours disponible et que les sources n’ont pas changé depuis le dernier build, Gradle est capable de sauter l’exécution de la tâche et de la marquer comme à jour. Cette fonctionnalité de build incrémental peut considérable diminuer le temps d’une tâche de build.

Si Gradle évalue qu’une tâche de test est à jour, même l’exécution de vos tests unitaires et sautée. Cela peut poser des problèmes lorsque vous lancer votre build Gradle avec Jenkins. Dans notre tâche de build simple ci-dessus, nous avons configuré une action à la suite du build pour publier les rapports JUnit de votre build. Si la tâche de test est sautée par Gradle, Jenkins marquera la tâche en erreur avec le message suivant :

Test reports were found but none of them are new. Did tests run?

Vous pouvez simplement résoudre ceci en invalidant la sortie et forcer une réexécution de vos tests en ajoutant le bout de code suivant dans votre fichier Gradle :

test {
    outputs.upToDateWhen { false }
}

Figure 5.52. Configurer une tâche de build Gradle

Après avoir ajouté le bout de code ci-dessus dans votre fichier de build, la sortie console de la tâche devrait ressembler à celle de la figure Figure 5.53, “Tâche incrémentale de Gradle”.

Figure 5.53. Tâche incrémentale de Gradle

Comme vous pouvez le voir, toutes les tâches exceptées test et uploadArchives ont été marquées comme à jour et n’ont pas été exécutées.

Jenkins est une application Java, mais il fournit aussi un excellent support pour les applications .NET.

Pour construire des projets .NET dans Jenkins, vous devez installer le MSBuild plugin.

Vous pourriez aussi vouloir installer le plugin MSTest et le plugin NUnit, pour afficher vos résultats de test.

Une fois que vous avez installé les plugins .NET et redémarré Jenkins, vous devez configurer vos outils de build .NET. Allez dans la page de configuration du système et spécifiez le chemin vers l’exécutable MSBuild (voir la figure Figure 5.54, “Configurer les outils de build .NET avec Jenkins”).

Figure 5.54. Configurer les outils de build .NET avec Jenkins

Une fois que vous l’avez configuré, vous pouvez retourner dans votre projet Freestyle et ajouter une étape de build .NET à la configuration.

Allez dans la section Build et choisissez l’option « Build a Visual project or solution using MSBuild » dans le menu Ajouter une étape de build. Ensuite, entrez le chemin vers votre script de build MSBuild (un fichier .proj ou .sln), avec n’importe quelle option de ligne de commande que votre script de build a besoin (voir la figure Figure 5.55, “Une étape de build utilisant MSBuild”).

Figure 5.55. Une étape de build utilisant MSBuild

Un autre moyen de construire vos applications .NET est d’utiliser NAnt. NAnt est la version .NET de l’outil de scripting de build largement utilisé dans le monde Java. Les scripts de build NAnt sont des fichiers XML (typiquement avec une extension .build), avec un format très similaire au script de build Ant.

Pour construire avec NAnt dans Jenkins, il vous faut installer le plugin NAnt de Jenkins. Une fois que vous l’avez installé et redémarré Jenkins, allez dans la page de configuration du système et spécifiez un répertoire d’installation NAnt dans la section NAnt Builder (voir la figure Figure 5.54, “Configurer les outils de build .NET avec Jenkins”).

Maintenant, allez dans la section Build de votre projet Freestyle et choisissez « Execute NAnt build » (voir la figure Figure 5.56, “Une étape de build utilisant NAnt”). Ici, vous spécifiez le script de build et la target que vous voulez invoquer. Si vous cliquez sur l’option « Avancée… », vous pouvez aussi spécifier des valeurs de propriété pour les passer dans le script NAnt.

Figure 5.56. Une étape de build utilisant NAnt

Jenkins est un excellent choix lorsqu’il s’agit de faire de l’IC sur vos projets Ruby et Ruby on Rails. Le plugin Rake vous permet d’ajouter des étapes de build Rake dans vos tâches de build. Vous pouvez aussi utiliser le plugin Ruby qui vous permet de lancer des scripts Ruby directement dans votre tâche de build. Finallement, le plugin Ruby Metrics fournit un support pour les outils de métriques de qualité de code comme RCov, Rails stats, et Flog.

Un autre outil précieux dans ce domaine est CI:Reporter.Cette librairie est un add-on de Test::Unit, RSpec, et Cucumber qui génère des rapports compatible avec JUnit de vos tests. Comme vous allez le voir, les résultats de test compatibles avec JUnit peuvent être utilisés directement par Jenkins pour faire des rapports de vos résultats de test. Vous devez installer CI:Reporter en utilisant Gem comme illustré ici :

$ sudo gem install ci_reporter
Successfully installed ci_reporter-1.6.4
1 gem installed

Ensuite, il vous faudra le configurer dans votre Rakefile, en ajoutant ce qui suit :

require 'rubygems'
gem 'ci_reporter'
require 'ci/reporter/rake/test_unit' # use this if you're using Test::Unit

Dans le chapitre Chapter 9, Qualité du Code, nous discutons de l’intégration des métriques de qualité de code dans vos builds Jenkins. Jenkins fournit aussi un support sur les métriques de couverture de code en Ruby. Le plugin Ruby Metrics supporte les métriques de qualité de code en utilisant rcov aussi bien que des statistiques de code générales avec Rails stats. Pour installer le plugin rcov, vous devez tout d'abord exécuter quelque chose comme les lignes suivantes :

$ ./script/plugin install http://svn.codahale.com/rails_rcov

Une fois que c’est configuré, vous serez en mesure d’afficher vos résultats de test et la tendance de résultat de test dans Jenkins.

Finalement, vous pouvez configurer un build Rake simplement en utilisant une étape de build Rake, comme illustré dans la Figure 5.57, “Une étape de build utilisant Rake”.

Figure 5.57. Une étape de build utilisant Rake

Vous devez aussi configurer Jenkins pour faire des rapports sur les résultats des tests et les métriques de qualité. Vous pouvez faire ceci en activant les options « Publish JUnit test result report », « Publish Rails stats report », et « Public Rcov report » (voir la figure Figure 5.58, “Publier des métriques de qualité de code pour Ruby et Rails”).Les rapports XML JUnit seront trouvés dans le répertoire results (entrez results/*.xml dans le champ “Test report XMLs”), et le rapport dans le répertoire coverage/units.

Figure 5.58. Publier des métriques de qualité de code pour Ruby et Rails