Переменные в GitHub Actions: Полное руководство по ENV, контекстам и управлению данными

Автоматизация процессов CI/CD (Continuous Integration / Continuous Deployment) сегодня является стандартом индустрии. Одним из самых мощных инструментов для этого стал GitHub Actions. Однако для создания гибких и масштабируемых пайплайнов недостаточно просто запускать скрипты — нужно уметь эффективно управлять данными.

В этой статье мы разберем, как работать с переменными в GitHub Actions: от использования встроенных переменных до создания собственных и управления их областями видимости.

Типы переменных в GitHub Actions

В экосистеме GitHub Actions существует два основных вида переменных:

1. Default Variables (Переменные по умолчанию) — предоставляются самим GitHub.
2. Custom Variables (Персональные переменные) — создаются разработчиком для нужд конкретного workflow.

Встроенные переменные (Default Variables)

GitHub автоматически предоставляет внушительный список переменных, которые содержат информацию о репозитории, событии (триггере), ветке и многом другом. Например:

• GITHUB_REPOSITORY — имя репозитория.
• GITHUB_REF — ветка или тег, вызвавшие запуск.
• GITHUB_SHA — ID коммита.

Эти переменные всегда пишутся в верхнем регистре (UPPER_CASE) и имеют префикс GITHUB_.

Области видимости (Scopes) персональных переменных

При создании своих переменных крайне важно понимать, где они будут доступны. В GitHub Actions существует трехуровневая иерархия:

1. Уровень Workflow: Переменная объявляется в корне YAML-файла (через ключ env:) и доступна во всех Jobs и Steps этого файла.
2. Уровень Job: Объявляется внутри конкретной задачи. Она видна только в рамках этой задачи и всех её шагов.
3. Уровень Step: Самая узкая область видимости. Переменная доступна только внутри одного конкретного шага.

Совет по именованию: Хотя GitHub не навязывает строгий регистр для ваших переменных, хорошей практикой считается использование UPPER_CASE с понятными префиксами (например, APP_STATUS или DB_NAME). Это позволяет сразу отличить переменную окружения от обычного текста в коде.

Синтаксис: Shell vs Context

Существует два способа обращения к переменным, и разница между ними критична для понимания работы раннера.

1. Использование через Shell ($VAR)

Когда вы пишете $MY_VARIABLE в блоке run, значение подставляется самой операционной системой (shell) на стороне раннера (виртуальной машины) в момент выполнения команды.

2. Использование через контекст GitHub (${{ env.VAR }})

Этот способ использует встроенный механизм выражений GitHub. В данном случае GitHub подставляет значение переменной еще до того, как команда будет отправлена на исполнение в shell. В логах это выглядит иначе: вместо команды с переменной вы увидите уже готовое значение.

Динамическое изменение переменных между шагами

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

Для решения этой задачи GitHub предоставляет специальный файл окружения, путь к которому хранится в переменной GITHUB_ENV.

Чтобы передать переменную в следующие шаги, используйте команду записи в этот файл:

run: echo "NEW_VAR=hello_world" >> $GITHUB_ENV

После выполнения этой строки переменная NEW_VAR станет доступна во всех последующих шагах текущего Job, даже если они не были связаны ранее.

Практические советы

• Безопасность: Никогда не выводите секретные данные (пароли, ключи) в логи через echo. Для конфиденциальной информации всегда используйте GitHub Secrets.
• Отладка: Если переменная не подхватывается, проверьте отступы в YAML-файле и убедитесь, что вы не пытаетесь обратиться к переменной шага из другого шага без использования $GITHUB_ENV.
• Документация: Список всех стандартных переменных постоянно обновляется, поэтому всегда полезно держать под рукой официальную документацию GitHub.

Заключение

Умение правильно распределять переменные по уровням видимости и динамически управлять их значениями — это ключ к созданию профессиональных и надежных CI/CD процессов. Используйте контексты для логики GitHub и переменные окружения для работы внутри скриптов, чтобы ваш код был чистым и предсказуемым.

Автор: Александр Сокирка

Занимаюсь веб разработкой с 2007 года. Имею большой опыт в веб-дизайне и разработке сайтов. Являюсь автором YouTube канала Быть Программистом. Основатель бренда Aletheme и автор тем для WordPress на маркетплэйсе Envato. С 2017 года занимаюсь обучением людей желающим стать программистами. Мои обучающие программы можно найти на этом сайте или на Udemy.