Кажется, я не могу найти наиболее очевидную функцию CI, которая когда-либо нужна от такого инструмента: запустить конвейер проекта после завершения конвейера другого проекта. Вы можете сделать это с помощью trigger, но только для последующего запуска, что противоположно тому, что вы хотите, если у вас есть проект, который является основной зависимостью от 20 других проектов, которые все должны быть перестроены.
В этом случае вам нужно определить что-то вроде:
Проект A : ничего особенного, просто обычный конвейер
Проект B , это "зависит" от проекта A:
.gitlab-ci.yml
from_upstream:
stage: pre
trigger:
project: ProjectA
Что он вызывает, вызывает построение ProjectB всякий раз, когда конвейер ProjectA имеет [ успешно] закончено.
Вместо этого вы должны объявить все десятки нисходящих потоков в ProjectA в подобном случае, что глупо и непродуктивно, особенно когда ProjectA является базовой библиотекой, которая постоянно используется везде.
Итак, кто-то может объяснить, почему в GitlabCI отсутствует очевидная функция (которая недоступна даже в EE), которая была в Bamboo и Hudson / Jenkins в течение десятилетий? И как мне делать то, что мне нужно, с Gitlab-CI?
ОБНОВЛЕНИЕ: Кажется, что понятие upstream / downstream действительно сбивает с толку некоторых людей, поэтому просто уточнить: upstream Проект A есть и всегда должен быть отделен от вниз по течению Проект B , потому что разделение интересов - это вещь, а сторонние разработчики не могли и не должны иметь никаких знаний о как их проект используется в нисходящем направлении.
Таким образом, желаемая функциональность (которая, опять же, существует в течение десятилетий в Bamboo и Jenkins) заключается в том, что нисходящие конвейеры объявляют пассивные триггеры в восходящих конвейерах, а не наоборот, когда активные триггеры как в настоящее время он реализован в Gitlab-CI.