События, workflow и правила job

Курс «Лаборатория GitLab CI/CD»

Лаборатория course-card уже строит и проверяет каталог. Теперь решим, какие события должны создавать pipeline. Коммит в ветке, открытие Merge Request, ручной запуск и тег имеют разное назначение. Если включить всё без явного договора, один push в ветку открытого Merge Request может создать две похожие проверки, а будущая ручная подготовка staging появится там, где она не нужна.

Нам требуется проверять ветку до Merge Request, затем использовать MR pipeline, а после объединения проверять default branch. Работу с Git и подготовку Merge Request можно изучить в отдельном курсе. Здесь интересует событие и состав конвейера, а не команды создания веток и разрешения конфликтов.

Два уровня решений

workflow:rules решает, создавать ли pipeline целиком. rules внутри job решает, включать ли конкретное задание в уже допустимый pipeline. Сначала определяется событие и общая конфигурация, затем выполняются jobs. Поэтому нельзя использовать значение, которое программа сборки вычислит позже, для выбора pipeline в этот же момент.

Добавьте следующий блок в начало нашего .gitlab-ci.yml, сохраняя default, stages, build-site и verify-site предыдущего шага. Это полный блок workflow, а не замена всех заданий файла.

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
      when: never
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH'
    - if: '$CI_PIPELINE_SOURCE == "web" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

Первое правило разрешает MR pipeline. Второе подавляет branch pipeline для push, если у ветки уже есть открытый Merge Request. Третье разрешает остальные push в ветки. Последнее оставляет ручной запуск через интерфейс для default branch. Если ни одно условие не совпало, pipeline не создаётся. В нашей учебной политике теги и расписания пока не включены.

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

Что означают переменные события

CI_PIPELINE_SOURCE сообщает происхождение pipeline. push охватывает события отправки изменений, включая теги, поэтому мы дополнительно проверяем CI_COMMIT_BRANCH. В MR pipeline эта branch-переменная не служит тем же признаком, что в обычном pipeline ветки. Поэтому MR допускаем по собственному source, а не пытаемся угадать его через имя ветки.

CI_DEFAULT_BRANCH позволяет не фиксировать слово main в каждой строке. В разных проектах основная ветка может называться иначе. Настройка проекта является источником этого значения. Наша конфигурация сообщает намерение «основная ветка», а не делает скрытое предположение об имени. Это особенно полезно при передаче лаборатории в другое учебное окружение.

Официальные примеры переключения между branch и MR приведены в документации workflow, а условия отдельных jobs — в документации правил заданий. Используем текущие правила, не смешивая их с историческими only/except в одном job.

Событие	Ожидаемое решение
Push в ветку без MR	Создать branch pipeline
Push в ветку с открытым MR	Подавить branch, использовать MR pipeline
Merge Request event	Создать MR pipeline
Push в default branch	Создать pipeline основной ветки
Tag или schedule	Не создавать в текущей учебной политике

Эта таблица — ожидаемая модель, а не результат выполненного запуска. При самостоятельной проверке важно сравнивать и source, и наличие открытого MR, а не только commit. Два pipeline одного commit могут быть допустимы для разных процессов, но в нашей лаборатории повторяющаяся проверка одного изменения не приносит новой информации.

Job, который нужен не везде

Позднее появится prepare-staging, доступный только после push в default branch и по ручному действию. Условие относится к конкретной работе, поэтому размещается в job rules. Нельзя перенести его в общий workflow: иначе мы вообще перестанем проверять изменения до объединения.

В то же время verify-site нужен в каждом разрешённом учебном pipeline. Не требуется копировать те же четыре правила внутрь этого job. Отсутствие отдельного ограничения позволяет включить его в допустимый процесс. Если потребитель артефакта запускается, а его производитель исключён правилом, возникает проблема графа; мы рассмотрим её вместе с needs.

С rules:changes можно пропускать действия, не связанные с изменёнными файлами. Однако вводить это ускорение прежде полного понимания зависимостей рано. Изменение генератора или шаблона должно запускать сборку даже при неизменном courses.json. Если включить job только для JSON, обновлённый HTML-код может остаться без проверки. Состав входов важнее удобства одной маски.

Проверьте мысленно порядок условий для ручного web-запуска. Он не равен push, поэтому ограничение дублей для открытого MR не должно случайно закрывать этот путь на основной ветке. Но последний web-разрешающий пункт не включает prepare-staging: у самого job есть более узкое условие push. Это осознанное различие. Если хотите разрешить подготовку также после web-запуска, потребуется изменить конкретное правило и описать новую политику. Нельзя считать, что разрешение pipeline автоматически разрешает все возможные actions. Таблица событий помогает увидеть такое несоответствие до выполнения программы.

Правила читаются сверху вниз до первого совпадения. Поэтому разрешение обычного push нельзя ставить раньше запрета второго pipeline для ветки с открытым Merge Request: широкий случай перехватит событие до более точного условия. При разборе запишите значения source, branch и open MR для конкретного случая, затем последовательно сравните их с условиями. Если ни одно workflow rule не совпало, pipeline не создаётся. Это объясняет отсутствие работы для тегов и schedules в нашей лаборатории без необходимости добавлять отдельное запрещающее правило на каждое возможное событие.

Просмотр конфигурации

Изображение Pipeline Editor из документации GitLab показывает поля сообщения, ветки и Merge Request. Имена на нём относятся к примеру документации; наша лаборатория в GitLab не запускалась.

При обсуждении конфигурации смотрите на итоговый состав jobs для выбранного события. Синтаксически допустимый YAML может исключить весь pipeline или оставить job без нужного производителя. Проверка правил должна отвечать на конкретное условие: push до MR, push после MR, ручной запуск или тег. Фраза «конфигурация валидна» не доказывает все эти сценарии.

Не создавайте реальное расписание только ради проверки этой главы. Пока schedule явно отсутствует в политике. Если вам потребуется регулярное действие, сначала определите его входы, назначение и срок хранения, затем добавьте source в workflow и нужные jobs. Новый способ запуска меняет договор процесса и должен быть виден в плане.

Ожидаемый результат — pipeline, создание которого объясняется событием, и правила, не порождающие двойную branch/MR-проверку в заданных условиях. Следующим шагом оформим результат сборки как артефакт конкретной версии, чтобы разрешённый запуск всегда сохранял понятное происхождение файлов.