blog.bressure.net

Voici la suite de mes aventures dans l’exploration des CI/CD. Je suis en train de modifier toute ma chaîne de build afin de pouvoir gérer des branches multiples et pour cela je capitalise mes trouvailles en fabriquant des archétypes de génération de projet que j’utilise aussi pour valider mes trouvailles. Encore un truc qui se mord la queue comme les acronymes à la GNU.

Afin d’appliquer à moi même l’obligation d’avoir des tests complets, je suis en train d’écrire le CI/CD de mon projet archétype blank qui doit produire une application vierge. Ce projet est un projet de type docker c’est-à-dire que le produit du build est une image docker. Donc effectuer des tests après le build consiste à exécuter une image docker.

Jusqu’à présent j’étais très puriste et exécutait mes tests d’image dans un démon docker monté pour l’occasion grâce à l’image Docker In Docker (DIND). Cependant le démo docker ainsi lancé et vierge à chaque construction et cela allonge le temps de test de beaucoup si il faut lancer plusieurs images comme c’est le cas si il faut exécuter un compose utilisant l’image que je veux tester en agrégeant d’autres services.

Je me suis donc lancé dans l’écriture de job en parallèle sans DIND.

Je tombe sur le hic illustré dans l’image en début d’article. Si avec DIND je peux naturellement lancer mon image de génération de code source et tester le résultat de sa production dans le job, sans DIND une fois le conteneur terminé, je ne vois pas le code produit depuis le job. En y regardant de plus prêt le job lance le conteneur mais ce dernier est à côté et donc isolé (c’est un peu le but de la conteneurisation aussi !) si bien que c’était comme si j’avais lancé le conteneur depuis l’hôte et que le job lui ne voit rien du tout.

Ccela me conforte dans l’idée de passer par DIND quand le conteneur à tester interagie avec l’hôte : en « bindant » des ports ou en produisant des fichiers sur l’hôte. DIND permet vraiment de reproduire l’utilisation réelle de l’image que je veux tester.

La carré montrant un gitlab-runner natif sur le schéma est juste là pour illustrer le cas. En utilisant un gitlan-runner natif j’obtiens bien-sûr le même résultat.