Jusqu’à présent, nous avons vu comment configurer Jenkins afin qu’il valide tout nouveau push effectué sur notre directory. Ici, nous allons voir comment lui faire effectuer différents tests qui permettront de voir directement si votre nouveau push est valide ou s’il introduit un bug quelconque qui empêcherait votre programme de fonctionner.

Tout d’abord, il faut savoir que Jenkins NE PEUT PAS supprimer un push. Il peut seulement rejeter automatiquement une pull request lorsque celle-ci échoue aux tests. Il ne servira donc ici qu’à vérifier que votre push ne contient pas d’erreurs. J’ajouterai que pour pouvoir utiliser correctement cet outil, il est nécessaire de le lier convenablement avec le repository Git désiré. C’est à cela que servent le webhook et le secret token qu’il vous a été demandés de recopier dans la partie settings/webhook de votre repository (si cela ne vous parle absolument pas, je vous conseille de commencer par faire l’exercice Git et Jenkins tutoriel et projet exemple qui se trouve à l’onglet du même nom sur le site Moodle du cours). En outre, le rôle de maintainer que vous avez attribué à Jenkins en l’invitant sur votre repository lui permet de cloner votre repo pour pouvoir effectuer les commandes que vous allez lui passer.

Pour passer des commandes, rendez-vous sur Jenkins dans l’onglet configure (configurer en français, à gauche avec le rouage) du job lié à votre projet. Allez dans la partie BUILD, dans la console de l’option “Exécuter un script shell”. Là, tapez les commandes bash que vous souhaitez que Jenkins effectue à chaque nouveau push, dans le même ordre que si vous les faisiez vous-même dans votre console. Ajoutez également des commandes de tests comme valgrind, cppcheck ou CUnit si vous le désirez. Il est aussi possible de créer un fichier Makefile dans lequel vous écrivez ces instructions et puis de seulement écrire les commandes make dans la console (pensez à commit le Makefile avant votre push pour éviter que Jenkins indique une erreur). Il est également conseillé de faire supprimer tous les fichiers non indispensables avant de demander à Jenkins de compiler vos codes et d’effectuer vos tests. Pour cela, mettez en tout premier (avant toute compilation ou test) dans la console “Exécuter un script shell” les suppressions adéquates à l’aide de la commande rm (n’oubliez pas d’ajouter le flag -f ou l’option --force afin d’éviter qu’un fichier inexistant ou inaccessible ne bloque votre build et fasse retourner une erreur par Jenkins). Comme précédemment, il est également possible d’effectuer ces suppressions à l’aide d’une commande make clean préalablement configurée dans votre Makefile (toujours avec le flag -f). N’oubliez pas d’apply et de sauver pour appliquer vos changements à Jenkins. Note : pour la compilation des programmes, il est nécessaire de rajouter l’option -std=c99 entre la mention gcc et le -o afin d’éviter une cascade d’erreurs de compilation une fois Jenkins lancé.

Ensuite, pour récupérer les résultats de vos tests, rendez-vous dans la partie “Actions à la suite du build” et sous “Ajouter une action après le build”, sélectionner à chaque fois un “Publish…” au nom d’un des outils de test que vous avez fait effectuer avec le shell. Recopiez le nom du fichier sous lequel vous avez fait sauvegarder votre rapport de test (càd les instructions --xml-file="valgrind.xml" etc. que vous avez rentrées dans la console ou le Makefile) précédé de */ dans l’onglet “Patern”. Ce symbole permet à Jenkins de chercher le rapport dans tout les directorys push et évite ainsi au logiciel de bloquer car il ne le trouverait pas. Apply et sauvegardez pour conserver vos modifications et vous devriez trouvez les résultats publiés par les outils de test à chaque nouveau build en cliquant dessus sur Jenkins. N’oubliez pas également de garder l’option “Publish build status to GitLab” afin de voir les résultats depuis votre répertoire Git.

Pour vérifier que tout fonctionne, rendez-vous sur votre répertoire Gitlab et effectuez un push qui passe vos tests et un qui les échoue (cela fonctionne même avec un seul test échoué). Après quelques instants, un V devrait apparaître pour le push valide et une croix dans le cas d’un push échoué.