Je n'arrive pas à trouver la fonctionnalité de CI la plus évidente dont on ait jamais eu besoin dans un tel outil : exécuter le pipeline d'un projet après que le pipeline d'un autre projet soit terminé. Vous pouvez le faire avec trigger mais seulement pour le déclenchement en aval, ce qui est le contraire de ce que vous voulez dans le cas où vous avez un projet qui est une dépendance principale de 20 autres projets qui doivent tous être reconstruits.
Ce dont vous avez besoin dans ce cas est de pouvoir définir quelque chose comme :
Projet A : rien de particulier, juste un pipeline normal
Projet B qui "dépend" du projet A :
.gitlab-ci.yml
from_upstream:
stage: pre
trigger:
project: ProjectACe qu'il fait, c'est déclencher la construction de ProjectB chaque fois qu'un pipeline de ProjectA a terminé [avec succès].
Au lieu de cela, vous devez déclarer toutes les douzaines d'avalanches dans ProjectA de la même manière, ce qui est stupide et contre-productif, surtout lorsque ProjectA est une bibliothèque centrale qui est constamment réutilisée partout.
Quelqu'un peut-il expliquer pourquoi il manque à GitlabCI une fonctionnalité évidente (qui n'est pas disponible même dans EE) qui existe dans Bamboo et Hudson/Jenkins depuis des décennies ? Et comment puis-je faire ce dont j'ai besoin avec Gitlab-CI ?
UPDATE : Il semble que la notion d'amont/aval soit vraiment confuse pour certaines personnes, donc juste pour clarifier : en amont Projet A est et doit toujours être découplé de en aval Projet B parce que la séparation des préoccupations est une chose et que les mainteneurs en amont ne pourraient et ne devraient pas avoir la moindre connaissance de la façon dont leur projet est utilisé en aval.
Ainsi, la fonctionnalité souhaitée (qui, encore une fois, existe depuis des décennies dans Bamboo et Jenkins) est que les pipelines en aval déclarent des déclencheurs passifs sur les pipelines en amont, et non l'inverse avec des déclencheurs actifs comme c'est actuellement implémenté dans Gitlab-CI.
