Après l'installation du plugin Git, une nouvelle section de configuration est disponible dans la page Administrer Jenkins→Configurer le système (voir Figure 5.8, “Configuration système du plugin Git”). Vous devez en particulier fournir le chemin vers l'exécutable de Git. Si Git est déjà installé sur votre système, entrez simplement “git” dans le champ.

Figure 5.8. Configuration système du plugin Git

Si le dépôt Git auquel vous accédez utilise SSH sans mot de passe comme moyen d'authentification—par exemple si l'adresse d'accès ressemble à git@github.com:matthewmccullough/some-repo.git—vous devrez fournir la partie privée de la clé sous forme de fichier ~/.ssh/id_rsa où ~ est le répertoire racine du compte utilisateur exécutant Jenkins.

L'empreinte du serveur distant devra additionnellement être ajoutée dans ~/.ssh/known_hosts pour éviter que Jenkins ne vous invite à accepter l'autorisation vers le serveur Git lors du premier accès alors que la console sera non interactive.

Alternativement, si vous avez la possibilité de vous connecter avec l'utilisateur jenkins, accédez par SSH à la machine Jenkins en tant que jenkins et faites une tentative manuelle de cloner un dépôt Git distant. Cela testera la configuration de votre clé privée et remplira le fichier known_hosts dans le répertoire ~/.ssh. C'est probablement la solution la plus simple de vous familiariser avec les subtilités de la configuration SSH.

Dans la plupart des cas, l'URL du dépôt Git que vous utilisez devrait être suffisante. Cependant, si vous avez besoin de plus d'options, cliquez sur le bouton Avancé (voir Figure 5.10, “Configuration avancée d'une URL de dépôt Git”). Cela apporte un contrôle plus précis sur le comportement du pull.

Le Nom du dépôt est un titre raccourci (ou remote en langage Git) pour un dépôt donné auquel vous pouvez vous reporter plus tard dans la configuration de l'action de merge.

La Refspec est un terme spécifique du langage Git pour contrôler précisément ce qui est récupéré depuis les serveurs distants et sous quel espace de nom c'est stocké localement.

Le champ Branch Specifier (Figure 5.11, “Configuration avancée des branches Git à construire”) peut être utilisé à l'aide d'un caractère générique ou en spécifiant le nom d'une branche à construire par Jenkins. Si le champ est laissé vide, toutes les branches seront construites. Pour le moment, lorsque vous sauvegardez votre tâche pour la première fois et qu'elle est configurée avec ce champ vide, il est alors rempli avec **, ce qui signifie "construire toutes les branches".

Figure 5.9. Remplir une URL de dépôt Git

Figure 5.10. Configuration avancée d'une URL de dépôt Git

Figure 5.11. Configuration avancée des branches Git à construire

Les régions (vues dans Figure 5.12, “Branches et régions”) sont des chemins nommés spécifiquement ou génériques de votre code source qui, même une fois modifiés, ne doivent pas déclencher de build. Il s'agit généralement de fichiers non compilés tels que les archives de locales ou d'images qui n'ont à priori pas d'effet sur les tests unitaires ou d'intégration.

Figure 5.12. Branches et régions

Le plugin Git vous permet également d'ignorer certains utilisateurs même s'ils effectuent des changements du code source qui auraient dû normalement déclencher un build.

Cette action n'est pas aussi méchante qu'elle peut paraitre : les utilisateurs exclus sont généralement des utilisateurs automatisés ou des développeurs non humains, qui ont des comptes distincts avec des droits de commit sur le gestionnaire de code source. Ces utilisateurs automatisés font généralement de petites opérations comme incrémenter la version d'un fichier pom.xml plutôt que de véritables changements dans la logique de votre application. Si vous souhaitez exclure plusieurs utilisateurs, ajoutez les simplement sur des lignes séparées.

Parfois vous aurez le besoin de récupérer directement le HEAD de manière séparée dans une branche au travers du hash d'un commit. Dans ce cas, spécifiez votre branche locale dans le champ “Checkout/merge to a local branch”.

Il est plus simple de l'illustrer par un exemple. Sans spécifier de branche locale, le plugin ferait quelque chose comme cela :

git checkout 73434e4a0af0f51c242f5ae8efc51a88383afc8a

Autrement, si vous utilisiez une branche nommée maBranche, Jenkins ferait la chose suivante :

git branch -D maBranche
git checkout -b maBranche 73434e4a0af0f51c242f5ae8efc51a88383afc8a

Par défaut, Jenkins clonera le dépôt Git directement dans l'espace de travail de votre tâche de build. Si vous préférez utiliser un répertoire différent, vous pouvez le spécifier ici. Notez que ce répertoire est relatif à l'espace de travail de votre tâche de build.

Le cas typique d'utilisation de cette option est le remplissage d'une branche d'intégration proche de la branche master. N'oubliez pas que seulement les fusions ne présentant pas de conflit seront effectuées automatiquement. Les fusions plus complexes qui requièrent une intervention manuelle feront échouer le build.

La branche fusionnée qui en résulte ne sera pas poussée automatiquement à moins que l'action de push ne soit activée dans les actions post-build.

Le taillage supprime les copies locales de branches distantes qui proviennent d'un clone précédent mais qui ne sont plus présentent sur le dépôt distant. En résumé, il s'agit du nettoyage du clone local pour qu'il soit parfaitement synchronisé avec son jumeau distant.

Active la purge de tout fichier ou répertoire non versionné, ramenant le votre copie de travail à son étât vierge.

Si vous utilisez les fonctionnalités de sous-modules de Git dans votre projet, cette option vous assure que chaque sous-module est à jour grâce à un appel explicite à la commande update, même si les sous-modules sont imbriqués dans d'autres sous-modules.

Jenkins note et affiche l'auteur du changement de code dans une vue synthétique. Git note l'auteur et le commiter du code distinctement, et cette option vous permet de choisir lequel apparaîtra dans le changelog.

Typiquement Jenkins réutilisera l'espace de travail, le rafraîchissant simplement si nécessaire et si vous avez activé l'option “Clean after checkout”, nettoiera les fichiers non versionnés. Cependant, si vous préférez avoir un espace de travail complétement propre, vous pouvez utiliser l'option “Wipe out workspace” pour supprimer et reconstruire l'espace de travail de zéro. Gardez à l'esprit que cela allongera significativement le temps d'initialisation et de construction du projet.

Jenkins decide quelle branches il doit construire en se basant sur une certaine stratégie (voir Figure 5.13, “Choix de la stratégie”). Les utilisateurs peuvent influencer cette procédure de recherche de branche. Le choix par défaut est de rechercher tous les HEADs de branche. Si le plugin Gerrit est installé, d'autres options pour construire tous les commits notifiés par Gerrit seront affichées.

Figure 5.13. Choix de la stratégie

Dans les options globales de Jenkins (voir Figure 5.14, “Configuration globale de l'exécutable de Git”), plusieurs exécutables Git peuvent être configurés et utilisés build par build. Cela est rarement utilisé et l'est seulement lorsqu'un clone ou d'autres opérations Git sont sensibles à une version particulière de Git. Git tend à être très flexible quant à ses numéro de version ; les dépôts légèrement anciens peuvent être clonés très facilement avec une nouvelle version de Git et inversement.

Figure 5.14. Configuration globale de l'exécutable de Git

Tout comme Subversion, Git a plusieurs navigateurs de source qu'il peut utiliser. Les plus couramment utilisés sont Gitorious, Git Web, ou GitHub. Si vous fournissez l'URL correspondante à votre navigateur de dépôt, Jenkins pourra alors afficher un lien direct vers les changements de votre code source qui ont déclenché le build (voir Figure 5.15, “Navigateur de dépôt”).

Figure 5.15. Navigateur de dépôt

Gerrit est une application web open source qui facilite les revues de code pour les projets dont les sources sont gérées par Git. Il lit le dépôt Git traditionnel et apporte une comparaison côte-à-côte des changements. Lorsque le code est revu, Gerrit apporte alors un lieu pour commenter et déplacer le patch dans un état ouvert, fusionné ou abandonné.

Le Gerrit Trigger est un plugin Jenkins qui peut déclencher un build Jenkins sur du code quand n'importe quelle activité liée à un utilisateur spécifique survient dans le projet d'un utilisateur défini du dépôt Git (voir Figure 5.18, “Déclenchement par Gerrit”). Il s'agit d'une alternative aux options plus régulièrement utilisées comme la construction périodique ou la scrutation de l'outil de gestion de version.

Figure 5.18. Déclenchement par Gerrit

La configuration de ce plugin est minimale et focalisée sur le Type du Projet et son Pattern ainsi que le Type de Branches et leur Pattern. Dans chaque paire, le type peut être Plain, Path ou bien RegExp — descriptif de ce qu'il faut observer — et la valeur (pattern) à évaluer en utilisant le type type comme guide.

Si une fusion ou tout autre action entraînant la création d'un commit a été faite pendant le build Jenkins, cette option peut alors être activée pour pousser les changements dans le dépôt distant.

Si une fusion au début du build a été configurée, la branche résultante est alors poussée vers son origine (voir Figure 5.20, “Fusionner les résultats”).

Figure 5.20. Fusionner les résultats

Lorsque vous poussez des étiquettes, chacune d'elle peut être nommée et choisie d'être créée si elle n'existe pas (ce qui échoue si elle existe déjà). Les variables d'environnement peuvent être utilisées dans le nom des étiquettes. Par exemple vous pouvez utiliser l'ID du process avec HUDSON_BUILD_$PPID ou même le numéro de build s'il est fourni par un plugin Jenkins avec $HUDSON_AUTOTAG_$BUILDNUM. Les étiquettes peuvent être ciblées sur un dépôt distant spécifique comme origin ou integrationrepo.

Le HEAD courant utilisé dans le build Jenkins d'une application peut être poussé dans d'autres dépôts distants lors d'une étape suivant le build. Vous n'avez à spécifier que la branche de destination et le nom du dépôt distant.

Les noms des dépôts distants sont validés en comparaison à la configuration précédemment faite du plugin. Si le dépôt n'existe pas, un avertissement est affiché.