Зависимости jobs с needs

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

Список стадий course-card задаёт крупный порядок: сначала build, затем verify. Когда в конвейере появится независимый анализ каталога, ждать всех jobs предыдущей стадии станет необязательно. Добавим needs, чтобы выразить реальные зависимости. Тогда задание начинается после нужного производителя и получает только предусмотренные файлы.

Граф задач не означает, что каждую работу нужно запускать как можно раньше. Зависимость должна отражать условие готовности. Проверка каталога требует готового dist/; аналитическая сводка исходного JSON не требует построенного HTML. Мы различим эти входы и сохраним договор проверяемого артефакта.

Ребро графа

В verify-site добавьте зависимость на build-site с явным получением артефакта. Остальные настройки, включая stage и script, остаются прежними. Этот фрагмент заменяет определение verify job в конфигурации предыдущего урока.

verify-site:
  stage: verify
  needs:
    - job: build-site
      artifacts: true
  script:
    - node scripts/verify.mjs

job ссылается на имя производителя, а не на stage. Если назвать его build, хотя в файле есть только build-site, зависимости не получится. artifacts: true сообщает, что потребителю нужны файлы этого job. Порядок и передача находятся рядом, но всё равно обозначены разными свойствами.

В схеме с needs GitLab не должен автоматически скачивать все артефакты предыдущих стадий. Потребитель получает их от указанных зависимостей. Это уменьшает случайное смешение файлов разных производителей и делает входы понятными. Не используйте одновременно needs и dependencies без ясной причины: для этой лаборатории достаточно одного механизма выбора артефактов.

Подробный принцип запуска по зависимостям раскрыт в документации needs. Граф не измерялся в нашем примере, поэтому не обещаем сокращение времени на определённый процент. Поясняем лишь, какие ожидания исчезнут и какие условия останутся обязательными.

Независимая сводка

Добавьте job analyze-catalog. Его программа читает courses.json и считает количество курсов и занятий. Она не использует dist/, поэтому зависимость на build-site ей не нужна. В следующем уроке эта работа послужит простым примером необязательного кэша. Сейчас анализ можно выполнить непосредственно из исходников.

analyze-catalog:
  stage: verify
  needs: []
  script:
    - node scripts/analyze.mjs

Пустой список needs означает, что job не ждёт завершения предыдущих стадий. Если доступен runner, он может стартовать сразу. Это не то же самое, что не писать needs вообще: без него действует обычный порядок stage. Поэтому пустой список следует добавлять сознательно, когда входы действительно независимы.

Анализ остаётся частью общего pipeline. Его ошибка не должна игнорироваться, если программа нарушает договор данных. Однако результат анализа не служит разрешением публикации. Для staging позднее потребуется цепочка от build через verify, а не просто первое зелёное задание. Назначение каждого результата важно даже при параллельном выполнении.

Что начинает зависимое задание

Представим два задания сборки: build-site и медленный build-preview. При одном порядке стадий verify мог бы ждать оба. С needs на build-site он ждёт только обязательный результат. Но если оба jobs пишут артефакты под одним именем и оба указаны в needs, файлы могут пересечься. Не складывайте несовместимые outputs в одинаковые относительные пути.

Для нашей лаборатории есть один производитель dist/. Сводка записывается отдельно, а отчёты проверки — в reports/. Такая география отражает смысл: сайт, сведения об исходных данных и диагностика. Когда по конфигурации можно предсказать, откуда появился каждый файл, разбор pipeline становится значительно проще.

Job	Вход	Обязательное ожидание
build-site	JSON, шаблон, генератор	Нет предыдущей сборки
analyze-catalog	JSON и анализатор	Нет зависимости от HTML
verify-site	dist от build-site	Успех build-site и получение артефакта
prepare-staging	Проверенный dist	Успех verify-site и исходный build-артефакт

Последняя строка пока является планом следующего этапа. Обратите внимание: ожидание verify не означает, что нужный dist/ обязательно хранится именно в его артефакте. Позднее укажем оба needs: verify для условия качества, build для файла выпуска. Иначе можно ошибочно скачать только отчёт проверки, оставшись без сайта.

Условия включения и optional

Rules могут исключить производителя из определённого pipeline. Если потребитель обязательно needs этот job, конфигурация может оказаться некорректной для события. Первое решение — согласовать правила включения. optional: true нужен только там, где отсутствие зависимости действительно допустимо, а не для скрытия нарушенного договора.

В нашем verify-site build обязателен всегда. Делать его optional было бы неверно: программа требует dist/. Для необязательного отчёта можно предусмотреть отсутствие файла и отдельное сообщение, но это другая задача. Граф должен отражать настоящие условия, даже если из-за них приходится расширить правило производителя.

Не проверяйте поведение графа лишь по расположению блоков YAML. Текстовый порядок jobs в файле не задаёт порядок выполнения. Имена, stages, needs и rules взаимодействуют между собой. Итоговую конфигурацию следует рассматривать для конкретного события и проверить через подходящие средства GitLab при самостоятельном запуске.

Когда потребитель получает несколько артефактов, заранее сравните их относительные пути. Например, два производителя с файлом dist/index.html не образуют два аккуратных сайта автоматически. Один путь может перекрыть другой при распаковке, и проверка увидит неожиданный результат. Для независимых outputs выберите разные папки или отдельные namespaced packages, затем укажите, что читает потребитель. В course-card одного производителя достаточно, поэтому не создаём такой конфликт искусственно. Разбор случая нужен для понимания того, что граф определяет ожидание jobs, а файловое пространство требует собственного понятного договора.

Needs также помогает отличать два вида готовности: необходимые файлы уже доступны, а обязательная проверка ещё выполняется. Для prepare-staging одной зависимости на build-site было бы достаточно, чтобы получить каталог, однако этого недостаточно для нашего договора качества. Добавленная зависимость на verify-site выражает именно разрешение после проверки, хотя её отчёты staging не читает. Поэтому artifacts: false у этого ребра не отменяет ожидание job. Оно лишь сообщает, что потребитель использует его результат выполнения и не нуждается в копии диагностической папки. Такое разделение удобно читать прямо в конфигурации.

Ожидаемая схема

После изменения ожидаем параллельное начало build-site и analyze-catalog, затем verify-site после получения нужного артефакта. Конкретное время зависит от доступности runner и выполнения программ. Если анализ оказался первым завершённым job, это не делает каталог готовым: он только посчитал исходные данные.

В архиве сохранён полный снимок этого этапа, чтобы можно было увидеть граф без восстановления предыдущих фрагментов. При подготовке серии ни pipeline, ни программы не выполнялись. Следующий урок добавит кэш к независимой сводке и покажет, почему отсутствие кэша должно менять скорость, сохраняя содержание результата.