Chapter 2.1 : Construction des images Docker



Cette section sera la première de notre configuration .gitlab-ci.yml puisque c'est elle qui construra les images Docker que nous utiliserons dans le reste de notre pipeline.

Afin de voir combien d'images sont nécéssaires, nous devons faire une petite liste des autres étapes de notre pipeline :

  • Intégration continue classique (chapitre 2.2) : on peut la définir en une ou deux étapes :
    1. Compilation du projet et tests unitaires avec les options de compilation de la release noteCela permet de ne pas avoir de biais car on teste le projet tel qu'il sera livré.
    2. Génération de la documentation et évaluation de la couverture des tests unitaires (avec des options de compilation différentes pour gcov et gcovr)
    La bonne nouvelle, est que l'on peut utiliser qu'une seule image (de votre OS préféré) pour ces étapes.
  • Contruction des releases automatiquement pour plusieurs OS (par exemple Ubuntu 20.04, Ubuntu 22.04, Fedora 31 et Fedora 36). Loin d'être annecdotique, cette multitude de système d'exploitation permet de vérifier que le projet compile bien même avec des compilateurs différents. Dans ce cas, on aura une image Docker par OS (dans notre cas : 4).


Donc, nous avons 5 images Docker à construire dans cette étape :
  • ci_build : pour les tests unitaires, la documentation et la couverture des tests (Dockerfile)
  • package_ubuntu2004 : pour créer des paquets sur Ubuntu 20.04 (Dockerfile)
  • package_ubuntu2204 : pour créer des paquets sur Ubuntu 22.04 (Dockerfile)
  • package_fedora31 : pour créer des paquets sur Fedora 31 (Dockerfile)
  • package_fedora36 : pour créer des paquets sur Fedora 36 (Dockerfile)
  • package_ubuntu2204_python3 : pour créer la release et uploader les paquets (Dockerfile)


Ne vous inquiétez pas, toutes les images Docker que vous construirez dans un projet seront accessibles dans les autres. Donc pas besoin de reconstruire les mêmes images pour chaque projet.


La définition des étape de notre CI sera : 
1
2
3
4
5

stages:
- Docker
- BuildTestinstall
- DocCoverage
- deploy


Il reste encore un petit détail à régler. Nous ne voulons pas que notre pipeline passe sont temps à construire des images docker qui ne changerons quasiment pas, voire pas du tout. Nous devons donc trouver un moyen de désactiver cette étape. À ce stade, le lecteur perspicace aura sans doute dans l'idée de commenter les jobs reliés à cette étape, ce qui est d'emblé très moche. Le lecteur plus perspicace aura noté dans la documentation de Gitlab la possibilité de désactiver des jobs avec l'option : 
1
2

rules:
        - when: always
Que l'on peut changer en : 
1
2

rules:
        - when: never
Pour désactiver les jobs que l'on veut.

Cette méthode est moins moche que celle qui consiste à tout commenter, mais on va quand même essayer de faire mieux. En effet, tout changement malencontreux de notre configuration .gitlab-ci.yml peut vite proser problème. Et nous ne voulons pas non plus lancer des jobs superflus à chaque commit car cela allongerait le temps d'exécution de notre pipeline de manière très significative.

Le CI de Gitlab nous permet d'avoir accès à de nombreuses variables, telles que ${CI_COMMIT_MESSAGE} et la configuration nous permet d'utilser des conditions. Nous pouvons donc imaginer quelque chose du genre noteEt non pas CI_COMMIT_MESSAGE car la rêgle foire avec cette variable. : 
1
2
3

rules:
        - if: $CI_COMMIT_TITLE == "docker"
                when: always


Ou, encore (mais dans une réalité alternative où cette idée aurait fait son chemin) : 
1
2
3
4

refs:
        - branches
        message:
        - docker


Qui permettrai d'activer la génération des images Docker si le message du commit contient le mot clé docker. Le détail de la configuration est donné dans la section 3.1.6.1.

Il serait, encore plus classe de vérifier si l'image Docker existe et de n'activer l'étape que si ce n'est pas le cas.