Опечатка в параметре CI-шаблона: проверяем inputs до запуска job

Общий CI-шаблон принимает окружение через переменную TARGET_ENV. Один проект передал stagign вместо staging. Pipeline создался, runner занял машину, и только deploy-скрипт обнаружил неизвестное значение. Когда параметр имеет небольшой набор допустимых вариантов, ошибку удобнее находить при сборке конфигурации, до запуска shell.

CI/CD inputs позволяют описать контракт подключаемого файла: имя параметра, тип, значение по умолчанию и ограничения. Это отличается от произвольной переменной окружения, которую команда читает уже во время выполнения. Для общего шаблона такой контракт особенно полезен: пользователю не нужно угадывать скрытые требования deploy-скрипта.

Объявить ограниченный параметр

В подключаемом файле inputs находятся в заголовке spec, отделённом от jobs строкой из трёх дефисов. Ниже параметр влияет только на понятное сообщение; это позволяет сначала проверить подстановку без настоящего деплоя.

spec:
  inputs:
    target:
      default: staging
      options: [staging, production]
---
show-target:
  script:
    - echo "Target is $[[ inputs.target ]]"

В вызывающем .gitlab-ci.yml задайте include:local с путём к этому файлу и inputs:target: staging. Если передать stagign, конфигурация должна быть отклонена как нарушающая объявленный набор вариантов. Для inputs в include используйте версию GitLab, где механизм поддерживается; inputs стали общедоступными в GitLab 17.0. Параметры запуска целого pipeline имеют отдельную историю версий, и их не нужно смешивать с этим примером.

Подстановка выполняется при подготовке конфигурации. Она не заменяет проверку значения, которое позже приходит из файла, внешнего сервиса или динамически вычисляется в shell. Также inputs не предназначены для хранения секретов. Имя окружения — удобный параметр конфигурации, а токен доступа должен идти через подходящий механизм секретов и права окружения.

Проверить обе стороны контракта

Начните с CI Lint или редактора pipeline и допустимого target. Посмотрите итоговую конфигурацию и убедитесь, что подставлен нужный текст. Затем намеренно передайте опечатку: проверка должна остановиться раньше выполнения job. После этого добавьте реальное действие, сохранив серверные проверки доступа к production.

Наличие production в options не даёт права развёртывать production. Оно лишь делает синтаксический выбор корректным. Разрешение на выпуск, правила запуска и защита секретов остаются отдельными механизмами. Это полезное разделение: контракт защищает от неверного параметра, а управление доступом — от недопустимого действия.

По мере развития общего шаблона документируйте inputs рядом с ним и меняйте их осознанно. Удаление старого варианта — изменение интерфейса для всех потребителей. Когда ошибки видны на этапе сборки YAML, команде проще обновлять проекты постепенно и понимать, какие значения поддерживает конкретная версия шаблона.

Продолжить практику

Исправление одной job полезно закрепить в полном процессе выпуска. В программе курса «GitLab CI/CD: автоматизация сборки и деплоя» — pipeline учебного приложения с проверками, тестами, сборкой Docker-образа, registry и staging. Отдельно разбираются runners, секреты, нестабильные запуски и возврат к предыдущему образу. Такой проект помогает увидеть, как решение внутри одной job влияет на выпуск версии и дальнейший откат.

Посмотреть программу курса

Источник: официальная документация.

Другие задачи по теме: Окружение задания и повторяемый pipeline.