Permettre à Jenkins d'effectuer des tests et de publier un feedback

[tbary]

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 où 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. Pour utiliser ce logiciel dans ce but, il faut d'abord créer un fichier makefile contenant les instructions que vous souhaitez passer à Jenkins. Ce peuvent être des compilations de programmes, des exécutions de tests CUnit, mais également des utilisations d'outils de débugage tels que valgrind ou cppchceck. Pensez également à introduire une commande make clean pour supprimer tout fichier indésirable. Ensuite, rendez-vous sur jenkins dans l'onglet configure (configurer en français, à gauche avec le rouage) du job lié à votre projet et dans la partie BUILD, dans la console de l'option "Exécuter un script shell", effectuez un make clean avant de faire la commande make qui permet d'exécuter les instructions de Jenkins. N'oubliez pas d'apply et de sauver pour appliquer ces changements à Jenkins. Enfin, 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 la commande make. Recopiez le nom du fichier sous lequel vous avez fait sauvegarder votre rapport de test (càd les instructions --xml-file="valgrind.xml" etc. de votre Makefile) précdé de */ dans l'onglet "Patern". 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 de jenkins depuis votre répertoire git.

Pour vérifier que tout fonctionne, rendez-vous sur votre répertoire gitlab et effectuez un push avec qui passe les 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é.

En espérant que tout ceci ait été utile, Tim Bary

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é.

[axelucl]

bonsoir,

Merci pour cette issue. Est ce que vous pourriez un peu améliorer le point sur les makefile.

Comme vous le dites vous même, il y a l'option exécuter un script shell. Une façon d'exécuter le script vue au cours est le makefile, mais on pourrait aussi taper des commandes directement.

Il faut aussi expliquer que make clean peut empêcher la validité du build si jamais il est appelé sans make (et donc qu'il n'y a aucun fichier à enlever, d'où l'option -f pour forcer dans le cours)

Cela serait bien aussi d'expliquer pourquoi on doit mettre le */.

Si vous pouvez aussi ajouter des informations sur les liens permissions GIT vs Jenkins, ça serait parfait. Merci d'avance, A. Legay

[tbary]

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 où 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 également 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.

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 la 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 bêtement 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 avec qui passe les 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é.

En espérant que tout ceci ait été utile, Tim Bary

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é.

[tbary]

Voilà ma seconde version ! Je ne suis juste pas certain de mes recherches sur le symbole */ et je ne suis également pas sur de répondre correctement à la dernière question... Pouvez-vous me confirmer tout cela ?

[axelucl]

bonsoir, c'est bien. Il faut éviter les mots comme "bêtement". Pour make clean, c'est correcte. Merci de faire la petite correction de forme et ça sera très bien. A. Legay

[tbary]

Voici la version avec les dernières modifications ! Comment dois-je faire ma pull request (mise en forme, titre etc.) ?

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 où 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.

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 la 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é.

En espérant que tout ceci ait été utile, Tim Bary

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é.

[obonaventure]

Bonjour, Merci. J'ai ajouté dans le README.md du blog sur GitHub des informations que comment faire le pull request en ligne. Pour la mise en page, regardez les articles précédents (en mode raw sur GitHub). La documentation Markdown est disponible via https://aksakalli.github.io/jekyll-doc-theme/docs/cheatsheet/ N'hésitez pas à revenir vers moi si vous avez des questions ou si le readme n'est pas clair.

[tbary]

Bonjour ! Je viens d'entrer une pull request qui a échoué car travis a détecté trop de fautes d'orthographe (qui sont en fait des mots comme apply, rm ou directory)... Qu'est-il possible de faire pour éviter cela ?

[tbary]

@axelucl @obonaventure Je viens encore de faire quelques corrections de typo et je n'ai dans mon article que des mots comme "push" ou "repository" que travis compte comme des erreurs... Serait-il éventuellement possible de valider ma pull request manuellement ?

[obonaventure]

il faut ajouter les mots hors dictionnaire dans le fichier .spelling, ne vous tracassez pas pour cela