C’est comme si le job de CI qui utilise le conteneur ne voyait pas l’upload de l’image réalisée par le job précédent qui crée l’image.
Relancer le pipeline résout souvent le problème, et il n’apparaît que de temps en temps, donc il doit potentiellement y avoir une composante non déterministe dépendant des conditions d’exécution (race condition ?).
Si côté admin vous voulez faire des expérience avec ma CI, notez que sous sa forme actuelle, ma config CI ne permet pas de relancer des jobs individuels, il faut lancer des pipelines complets. C’est à cause d’un workaround que l’utilise pour contourner le fait que la fonction ramasse-miettes du registry GitLab ne fonctionne pas, ou en tous cas ne fonctionnait pas sur l’hébergeur d’une version précédente de ce dépôt (gitlab.in2p3.fr).
Le problème qui s’est produit dans votre situation vient de la plateforme kubernetes qui héberge le runner (PLMApps). Ces derniers temps, nous avons quelques ralentissements qui peuvent générer ce genre de problème.
PLMLab met à disposition deux runners, l’un sur PLMApps (kubernetes à Grenoble), l’autre sur PLMShift (kubernetes à Bordeaux). Il vous est possible de créer votre propre runner pour utiliser une machine de votre coté.
Cordialement
Merci pour ces précisions! N’hésitez pas si il y a quoi que ce soit que je peux faire ou fournir comme info de mon côté pour vous aider à debugger ce type de soucis, qui reste peu fréquent.
De mon côté, je suis un peu en surcharge pro en ce moment, donc j’aimerais éviter de m’ajouter du travail de maintenance pour une machine de plus (sous la forme d’un runner gitlab, donc d’une VM de plus à maintenir à jour et bichonner le jour occasionnel où une update gitlab casse ma config).
J’apprécie donc énormément le travail qui est fait pour fournir ces runners partagés, qui sont à l’heure actuelle très suffisants pour mes besoins.