Стадии: порядок работ и остановка на падении

Зачем делить на стадии

Одного job хватает ровно до момента, когда работ становится больше одной. Собрать, проверить, выложить — эти шаги должны идти в определённом порядке, и выкладывать имеет смысл только то, что прошло проверку.

Порядок задают стадии. Список стадий объявляется один раз сверху, каждый job говорит, к какой стадии относится.

stages:
  - build
  - test

build-site:
  stage: build
  script:
    - echo "Собираем сайт"
    - test -f index.html

check-title:
  stage: test
  script:
    - grep "<title>" index.html

Запушьте это в свой проект вместо прошлого конфига. На странице пайплайна появятся два кружка вместо одного, по кружку на стадию.

Как это выполняется

Стадии идут строго последовательно: пока не закончится весь build, ни один job из test не стартует.

Внутри одной стадии всё наоборот: jobs запускаются параллельно, если свободны раннеры. Два теста в стадии test побегут одновременно и общее время не удвоят.

Пайплайн из двух стадий с такими командами отрабатывает около 40 секунд, вдвое дольше одного job. Контейнер поднимается на каждый job заново, а не переиспользуется.

Падение останавливает пайплайн

Проверьте главное свойство стадий руками. Сломайте команду в build:

build-site:
  stage: build
  script:
    - echo "Собираем"
    - test -f nonexistent.html

Результат на странице пайплайна:

build-site   Failed
check-title  Skipped

Skipped, а не Failed. Стадия test даже не запускалась: GitLab не стал тратить раннер на проверку того, что не собралось.

Отсюда правило порядка стадий: чем дешевле и быстрее проверка, тем раньше она должна стоять. Линтер, который падает за пять секунд, экономит десять минут интеграционных тестов.

Имена стадий ничего не значат

build, test, deploy — просто строки. GitLab не знает, что «build» это сборка, и не проверяет, что вы там делаете. Значение имеет только порядок в списке stages.

Если стадии не объявлять вообще, GitLab использует свой список: .pre, build, test, deploy, .post. Служебные .pre и .post всегда идут самой первой и самой последней стадией, что бы вы ни написали. Job без указанной стадии попадает в test, поэтому пайплайн из прошлого урока и работал без слова stages.

Пробовать конфиг, не ломая main

Гонять эксперименты в основной ветке необязательно. Пайплайн запускается на любой ветке:

git checkout -b pipeline-test
git push -u origin pipeline-test

В списке пайплайнов рядом с именем коммита будет имя ветки. Наигрались, слили в main или удалили ветку.

Что важно запомнить

stages сверху файла задаёт порядок; stage: в job говорит, где он стоит.

Стадии идут по очереди, jobs внутри стадии работают параллельно.

Упавшая стадия отменяет все последующие: они получают статус Skipped.

Дешёвые проверки ставим раньше дорогих, тогда пайплайн падает быстрее и меньше жжёт минут.

Дальше передаём собранные файлы из одной стадии в другую.