Дочерний pipeline упал, а родитель зелёный: strategy mirror и статус запуска

Родительский pipeline завершился успешно, хотя в дочернем упали тесты. На графе связь есть, дочерние jobs действительно выполнялись. Причина может быть в trigger job: по умолчанию её успех означает, что GitLab создал downstream pipeline. Дожидаться результата всех его проверок она без дополнительной настройки не обязана.

Это важно, когда следующая стадия родителя публикует релиз. Сам факт запуска дочерних тестов ещё не делает их барьером перед публикацией. Для такой зависимости в GitLab 18.2 и новее доступна trigger:strategy: mirror. На более старой установке этот синтаксис не поддерживается; сначала проверьте версию сервера.

Воспроизведём ошибку в дочерней проверке

В тестовом репозитории создайте основной файл и ci/child.yml. Здесь нет настоящего релиза: финальная job только печатает SHA, до которого разрешено дойти после проверки.

# .gitlab-ci.yml
stages: [verify, finish]

child_tests:
  stage: verify
  trigger:
    include:
      - local: ci/child.yml
    strategy: mirror

finish:
  stage: finish
  image: alpine:3.21
  script: printf '%s\n' "$CI_COMMIT_SHA"

# ci/child.yml
child_check:
  image: alpine:3.21
  script:
    - test 2 -eq 3

С намеренно неверным сравнением child_check завершается с ненулевым кодом. Child_tests должна отразить ошибку дочернего pipeline, а finish не должна исполняться по обычному правилу успешности предыдущих стадий. Затем замените сравнение на test 2 -eq 2: дочерний запуск и trigger должны завершиться успешно, после чего finish получит управление.

Для сравнения можно убрать strategy в отдельной тестовой ветке. Тогда trigger способен завершиться успешно сразу после создания ребёнка, и дальнейшая стадия родителя больше не ждёт его результата. Сопоставляйте три статуса: child_check, весь дочерний pipeline и trigger job. Так видно, где именно потерялась зависимость.

Mirror отражает итоговую политику дочернего pipeline

Если child_check помечена allow_failure: true, её ошибка может не делать весь дочерний pipeline неуспешным. Mirror отражает статус pipeline, а не правило «любая красная строка в любом потомке запрещает релиз». Поэтому обязательность теста задаётся в конфигурации самого ребёнка.

Аналогично ведут себя ручные задачи. Optional manual job может остаться незапущенной и не мешать успешному завершению. Blocking manual job удерживает pipeline до решения оператора и влияет на ожидание родителя. Перед включением mirror проверьте, не находится ли в дочернем сценарии ручной шаг, который команда считала необязательным.

Создание и выполнение остаются разными этапами

Ошибка чтения child.yml или отсутствие разрешённых jobs мешает созданию downstream pipeline. Она отличается от падения уже запущенного теста. В первом случае проверьте путь include и rules ребёнка. Для parent-child pipeline источник внутри ребёнка — parent_pipeline; условие только по source == push может исключить его задачи.

Если нужны MR-условия, учитывайте переменные, переданные из родительского контекста, а не ожидайте merge_request_event у child pipeline. Такой сценарий следует проверять отдельным MR, потому что успешный branch pipeline не доказывает правильность отбора в дочернем контексте.

Для старых конфигураций встречается strategy: depend. Его поведение в отдельных статусах отличается, и текущий GitLab рекомендует mirror. Обновлять стоит после проверки версии и матрицы ошибок, ручных jobs и отмены, а не простым поиском и заменой по всем проектам.

Что не передаётся вместе со статусом

Ожидание завершения не создаёт автоматическую передачу всех файлов, переменных и отчётов. Если родителю нужен результат дочерней сборки, опишите получение конкретного artifact или пакета отдельно. У статуса и входных данных разные договорённости: зелёный child pipeline может проверить код, но не хранить нужный архив.

После изменения в рабочем процессе проверьте искусственное падение обязательного теста на стенде. Релизная стадия должна остановиться именно на ожидании нужного результата. Когда положительный и отрицательный сценарии работают, связь на графе приобретает проверяемый смысл: родитель продолжает работу после завершённых успешных проверок, а не после их создания.

Ещё по теме

• GitLab CI запускает два pipeline на один push: разбираем workflow и rules
• GitLab pipeline не создаётся из-за needs: условные jobs и optional

Продолжить изучение

Хотите собрать проверяемый путь от коммита до релиза? Jobs, runners, артефакты и деплой — темы программы «GitLab CI/CD: автоматизация сборки и деплоя».