Переменная GitLab CI пустая: protected, environment scope и тип File

Job завершилась сообщением missing credentials, хотя токен есть в настройках проекта. Печатать его через echo — плохой способ выяснить причину: даже успешная диагностика оставит значение в журнале. Полезнее проверить, появилась ли переменная, какой у неё тип и соответствует ли запуск условиям доступа.

Разберём переменную APP_TOKEN для публикации и APP_CA_FILE с сертификатом. Токен должен приходить как значение, сертификат — как путь к временному файлу. У обоих могут быть ограничения по защищённым refs и окружению. Каждое ограничение проверяется независимо от правильности имени ключа.

Отсутствует, пуста или содержит путь

В тестовой job на Linux с POSIX shell можно проверить состояние без содержимого. Фрагмент ниже относится к script существующей job и ничего не отправляет во внешнюю систему.

if [ "${APP_TOKEN+x}" != x ]; then
  printf '%s\n' 'APP_TOKEN is unset' >&2
  exit 1
fi
if [ -z "$APP_TOKEN" ]; then
  printf '%s\n' 'APP_TOKEN is empty' >&2
  exit 1
fi
if [ -z "${APP_CA_FILE:-}" ] || [ ! -r "$APP_CA_FILE" ]; then
  printf '%s\n' 'APP_CA_FILE is not a readable file' >&2
  exit 1
fi
printf '%s\n' 'Required inputs are available'

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

Для File-переменной GitLab записывает сохранённое содержимое во временный файл, а в переменную окружения помещает путь. Поэтому передавайте APP_CA_FILE параметру, который ожидает имя файла. Если инструмент ждёт текст, путь будет воспринят как текст и вызовет другую ошибку.

Защищённая переменная и обычная ветка

Сравните protected-статус переменной и ref pipeline. Токен с Protected доступен только в разрешённых защищённых контекстах. Main может проходить, а feature-ветка не получать токен — это согласованное ограничение, если публикация предназначена только для релиза.

Для merge request pipeline доступ к защищённым переменным зависит от условий GitLab и настроек проекта, включая защищённость исходной и целевой ветки. Одного имени target branch недостаточно. Посмотрите источник запуска и правила доступа к protected variables именно для вашей версии. Если job только тестирует код, разумнее дать ей отдельный тестовый вход, чем расширять область релизного токена.

Environment scope относится к job

Переменная со scope production выбирается по environment задачи. Job без environment: production не приобретает этот scope из имени stage deploy. Проверьте итоговое имя окружения, особенно если оно строится из переменных: review/branch и production — разные значения.

check_release_inputs:
  image: alpine:3.21
  environment:
    name: production
  script:
    - test -n "${APP_TOKEN:-}"
    - test -r "${APP_CA_FILE:-}"

Это минимальный пример сопоставления scope, а не разрешение выдавать production-секрет всем веткам. В рабочем файле добавьте rules, ограничивающие допустимый источник релиза, и используйте принятый порядок авторизации. Ограничения самой переменной продолжают действовать независимо от environment.

Когда значение перекрыли другим

Если переменная есть, но пуста, найдите одноимённый ключ на уровне группы, проекта, YAML и аргументов ручного или API-запуска. Приоритет источников переменных может привести к тому, что сохранённое значение перекрывается переданным пустым. Сравнивайте имена и области, не выгружая все значения в журнал.

Проверьте также раскрытие ссылок на другие переменные. Настройка expansion и допустимый формат значения влияют на то, будет ли строка с долларом раскрыта или передана буквально. Masked отвечает за сокрытие в выводе, Protected — за контекст выдачи; одно свойство не заменяет другое.

Завершайте диагностику повторным запуском в разрешённом контексте и отрицательной проверкой вне него. В первом входы должны быть доступны, во втором релизная job не должна получать секрет. Такая проверка подтверждает и работоспособность публикации, и сохранение выбранной границы доступа.

Ещё по теме

• Cache и artifacts в GitLab CI: как передать результат сборки следующему job
• GitLab CI запускает два pipeline на один push: разбираем workflow и rules

Продолжить изучение

Хотите собрать проверяемый путь от коммита до релиза? Jobs, runners, артефакты и деплой — темы программы «GitLab CI/CD: автоматизация сборки и деплоя».