Порядок этапов Gitlab-ci игнорируется, когда правила включают изменения
рассмотрите следующий gitlab-ci.yaml для монорепозитория с несколькими микроинтерфейсами
stages:
- build
- deploy
build:app1:
stage: build
script:
- sleep 30
- mkdir dist1
- touch dist1/output1.html
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
changes:
- app1/src/*
artifacts:
paths:
- dist1
build:app2:
stage: build
script:
- sleep 30
- mkdir dist2
- touch dist2/output2.html
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
changes:
- app2/src/*
artifacts:
paths:
- dist2
deploy:all:
stage: deploy
script:
- mkdir dist
- cp dist1/* dist
- cp dist2/* dist
- deploy.sh ./dist
artifacts:
paths:
- dist
при запуске порядок, определенный в этапах, игнорируется, и задания сборки и развертывания выполняются одновременно. вызывая сбой задания «deploy: all» (поскольку оно все еще «строится»)
если я удаляю условие для changes, порядок этапов соблюдается, и сборка выполняется до развертывания
как я могу действовать только в отношении изменений и обеспечивать соблюдение определенного порядка сборки?
в реальном монорепозитории 10 микрофронтендов, а не 2...
@ПьерБ. нет это единственный конфиг
Интересно, возникает ли проблема из-за того, что ваши правила означают, что Gitlab запускает конвейер запросов на слияние, а также конвейер ветвей. Вы видите два работающих конвейера? Затем вам может потребоваться добавить раздел рабочего процесса, чтобы решить эту проблему.
@kmt это было :)
Ответы 3
В вашем случае вы можете попробовать использовать ключевое слово needs, чтобы установить отношения между заданиями: https://docs.gitlab.com/ee/ci/yaml/#needs
Вам также необходимо добавить optional: true, так как у вас есть условия правил в ваших заданиях сборки.
Вы можете добавить его в свою работу deploy:all следующим образом:
deploy:all:
needs:
- job: build:app1
optional: true
- job: build:app2
optional: true
stage: deploy
script:
- mkdir dist
- cp dist1/* dist
- cp dist2/* dist
- deploy.sh ./dist
artifacts:
paths:
- dist
Будет ли это ждать завершения всех заданий или оно сработает, как только одно из них будет выполнено? Я попробую и посмотрю, работает ли это. Это будет здорово, если это произойдет. Я думал об этом, но я думал, что он сработает, как только завершится одно из заданий, вместо того, чтобы ждать их всех... Однако твердое предложение. Я попробую и посмотрю, как это работает
это стоило того, но использование этой техники по-прежнему запускает развертывание одновременно для обоих заданий... на самом деле не ожидая ни того, ни другого.
На этапе развертывания также может потребоваться условие для изменений. Если, возможно, вам не нужно, чтобы этап deploy:all выполнялся всегда, независимо от того, есть изменения или нет.
Также в вашем случае всегда полезно указать, что этап развертывания нуждается в артефактах, потому что ваш этап развертывания в любом случае использует артефакты.
needs:
- job: build:app1
artifacts: true
- job: build:app2
artifacts: true
Когда я запускаю ваш gitlab_ci.yml в Gitlab CI, он не запускает задачи сборки и развертывания одновременно. Он запускает конвейер запросов на слияние (с заданиями сборки) и конвейер ответвлений (с заданием развертывания). Поскольку артефакты из заданий сборки создаются в конвейере мерж-реквестов, они недоступны для конвейера ответвления, поэтому задание развертывания завершается сбоем.
Трудно сказать, как это исправить, не зная, каково ваше намерение, но вам нужно запускать задания сборки и развертывания в одном и том же конвейере, поэтому либо запускайте задание развертывания с
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
или запустите задания сборки в ответвленном конвейере.
Кроме того, мне непонятно, как вы ожидаете, что задание развертывания всегда будет работать, как если бы вы запускали задания сборки только тогда, когда есть изменения, иногда не каждое задание сборки будет иметь артефакт, и ваше задание развертывания завершится ошибкой.
это кажется наиболее многообещающим ответом ... я попробую и приму его, если он решит проблему .... это монорепозиторий с микро-интерфейсом (single-SPA) ... поэтому я буду создавать и развертывать только то, что необходимо менять... Не нужно каждый раз все перестраивать...
Это единственная и полная конфигурация CI в вашем репозитории или у вас есть другие? Где-то есть
include? Это может изменить поведение вашего конвейера