Si vous utilisez Gitlab CI, vous avez probablement remarqué que, lors de l’exécution d’un pipeline (script d’intégration continue), l’ordonnanceur attend que tous les jobs (tâches) d’un stage (étage du pipeline) soient terminés avant d’exécuter les jobs des stages suivants, même si leurs dépendances sont satisfaites (i.e. tous les jobs du stage précédent dont ils dépendent sont terminés). Ce comportement présente deux inconvénients :

  • Le temps d’exécution global du pipeline n’est pas optimisé puisque truffé d’attentes inutiles.

  • Corollaire du premier inconvénient, le pipeline réserve plus longtemps les ressources matérielles allouées, ce qui augmente le cout de l’intégration continue, notamment lorsque ces ressources sont louées à un cloud provider, comme c’est le cas pour le projet Orfeo Toolbox. Mais même lorsqu’on utilise une infrastructure interne mutualisée, il convient d’en faire un usage optimal pour ne pas l’engorger.

Conscients de ce problème, les développeurs de Gitlab CI ont introduit il y a quelques mois le calcul du graphe orienté acyclique des dépendances. Pour cela, ils auraient pu exploiter le mot-clé dependencies qui existait déjà et semblait tout désigné, mais ils n’ont pas voulu altérer la logique sous-jacente, répondant à un but différent de celui poursuivi ici. Ils ont donc préféré introduire un nouveau mot-clé dans la syntaxe : needs.

Malheureusement, l’implantation initiale n’avait pas anticipé certains besoins et il a fallu attendre la sortie de la version 12.7.0 de Gitlab (publiée le 22 janvier) pour que cette fonction puisse être utilisée de manière satisfaisante. Sitôt celle-ci disponible, je me suis attelé à la tâche d’adaptation du pipeline du projet Orfeo Toolbox.

Maintenant, nous allons devoir attendre un peu pour évaluer l’impact effectif de cette nouvelle stratégie sur le temps d’exécution du pipeline, mais vu la multiplicité des jobs et les écarts de durée entre eux, je devine que nous allons gagner du temps.

Mise à jour le 13 mars 2020 : Voici un mois et demi que nous avons effectué la bascule et nous avons maintenant assez de recul pour évaluer l’impact de cette modification. Le temps minimal d’exécution du pipeline est passé de 1h24 à 1h14. Nous avons donc gagné 10 minutes en optant pour l’exécution des tâches au plus tôt. 10 minutes, c’est bien pour une modification aussi triviale, mais cela n’est pas suffisant pour nous faire passer en dessous de la barre symbolique – et économique vu le modèle de facturation d’OVH – de l’heure.