Версия вычислена в build, но пропала в следующей job: отчёт dotenv

Во время сборки вычислили имя пакета и экспортировали PACKAGE_VERSION. В этой job переменная видна, а следующая получает пустую строку. export передаёт значение дочерним процессам текущей оболочки; он не меняет окружение будущего процесса на другом runner. Для передачи результата между jobs нужен явный канал.

Если результат — небольшое значение, которое следующая job должна читать как переменную окружения, GitLab поддерживает отчёт dotenv. Производитель сохраняет строки NAME=value, GitLab загружает файл как report, а потребитель получает значения при подготовке своей среды. Это удобно для вычисленной версии или адреса подготовленного окружения.

Минимальный pipeline без публикации

Пример не обращается к registry и не выкладывает приложение. Первая job формирует идентификатор из предопределённой переменной GitLab, вторая только печатает полученное значение.

stages: [build, inspect]

make-version:
  stage: build
  image: alpine:3.22
  script:
    - printf 'PACKAGE_VERSION=build-%s\n' "$CI_PIPELINE_IID" > build.env
  artifacts:
    reports:
      dotenv: build.env

inspect-version:
  stage: inspect
  image: alpine:3.22
  needs:
    - job: make-version
      artifacts: true
  script:
    - test -n "$PACKAGE_VERSION"
    - printf 'package=%s\n' "$PACKAGE_VERSION"

Если IID текущего pipeline равен 42, вторая job напечатает package=build-42. IID не следует вручную фиксировать в рабочем YAML: пример результата нужен для понимания, а значение приходит от запуска GitLab. test проверяет, что канал передачи не остался пустым.

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

Почему значение не подходит для rules

Правила создания jobs вычисляются до выполнения make-version. Файл build.env ещё не существует, поэтому его значения не могут управлять rules этого же pipeline. Если условие известно только после сборки, решение нужно принимать внутри выполняемой job либо проектировать отдельный следующий pipeline с явно переданными входами.

Не путайте поздно вычисленную переменную с заранее определённой настройкой запуска. Например, пользовательский флаг RELEASE_REQUESTED существует при создании pipeline и может участвовать в rules. Версия, прочитанная из только что собранного пакета, появляется позже. Одинаковый синтаксис $NAME не делает их доступными в один момент.

Формат маленький и строгий

dotenv в GitLab имеет ограничения: значения должны быть однострочными, комментарии и пустые строки не допускаются, а кавычки не работают как в shell-файле. Это не универсальный способ передать произвольный документ. Для JSON manifest используйте обычный artifact и парсер в потребителе.

Не помещайте секреты в dotenv-отчёт. Пользователи с доступом к артефакту могут скачать файл. Для токенов и ключей нужны штатные механизмы секретов и переменных с подходящей областью доступа. Отчёт полезен для результата вычисления, который допустимо хранить вместе с данными сборки.

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

Откройте программу GitLab CI/CD. В ней есть зависимости jobs, переменные, артефакты и выпуск приложения. Продолжите к pipeline, где версия вычисляется один раз, передаётся по явному пути и используется для сборки и контролируемой доставки одного артефакта.

Ещё по теме

• after_script не видит export и cd: передаём состояние файлом
• GitLab не нашёл artifacts после cd: путь считается от каталога проекта