Какими способами в GitLab прикрепить downstream pipeline для запуска тестов
Что проверяют
Знаете ли вы разницу между parent-child и multi-project пайплайнами и умеете ли связать статус тестов с основным пайплайном. Следом спрашивают, как передать в тесты переменные и артефакты сборки.
Как отвечать
Основной инструмент это задание с ключевым словом trigger, script в нём не пишут. Варианты:
- дочерний пайплайн в том же проекте:
trigger: include: ci/tests.yml. Тесты живут в отдельном файле и запускаются только при изменениях в нужных каталогах черезrules: changes; - динамический дочерний пайплайн: одно задание генерирует YAML, например Python-скрипт создаёт по заданию на каждый изменённый пакет и сохраняет файл в артефакт, а trigger-задание запускает его через
include: - artifact: tests.ymlс указаниемjob; - multi-project пайплайн:
trigger: project: group/e2e-testsиbranch: main. Так запускают тесты из отдельного репозитория QA; - API с триггер-токеном:
POST /api/v4/projects/:id/trigger/pipelineсtokenиref. Если передать вtokenзначениеCI_JOB_TOKEN, GitLab покажет пайплайн как связанный downstream.
Дальше про связку. По умолчанию trigger-задание зеленеет сразу после создания downstream, и упавшие тесты не блокируют мерж. strategy: depend заставляет его дождаться и повторить статус downstream. Переменные передают через variables в trigger-задании, проброс настраивают в trigger: forward (yaml_variables, pipeline_variables). Артефакты сборки дочерний пайплайн забирает через needs: - pipeline: $PARENT_PIPELINE_ID с указанием job, а саму переменную родитель передаёт из CI_PIPELINE_ID.
Где спотыкаются
Называют needs способом прикрепить пайплайн. Это зависимость между заданиями внутри одного пайплайна, downstream так не создаётся.
Понимают strategy: depend наоборот, как «запустить после успеха upstream». На деле upstream ждёт завершения downstream и берёт его статус.
Пытаются забрать артефакт в чужом проекте так же, как в дочернем пайплайне. Для multi-project нужен needs: project, и он есть не на всех тарифах.