GitHub Actions lockfile фиксирует код запуска, но не весь CI

Можно ли доверять GitHub Actions, если workflow ссылается на action по тегу вроде @v3? Lockfile уточняет, какой commit action будет выполнен, даже если тег позднее переместится. Команда может просматривать обновления зависимостей в diff и вести проверяемый список actions, используемых CI. Практическая граница: lockfile охватывает actions, вызываемые шагами, а reusable workflow, вызванный на уровне job, нужно фиксировать отдельно. Описанный механизм доступен в GitHub Enterprise Cloud.

Что именно фиксирует lockfile?

Ссылки на ветки и теги удобны, но их адресуемая версия может меняться. Запись вроде uses: octo-org/deploy-action@v3 указывает на имя тега; GitHub разрешает эту ссылку в commit при запуске. Если владелец проекта передвинет тег, следующий запуск без зафиксированной зависимости может получить другой код.

Согласно документации GitHub о lockfile, файл .github/workflows/actions.lock хранит ссылки на зависимости и соответствующие commit SHA, включая транзитивные зависимости — actions, которые используют другие actions. Файл создаёт расширение GitHub CLI gh actions-lock; вручную его не редактируют.

Генератор также может уточнить ссылки uses в workflow-файлах: например, сделать ссылку на плавающий тег более конкретной, сохранив commit, который она разрешала при создании lockfile. Поэтому при внедрении нужно просматривать весь diff — изменения workflow и lockfile — и проверять, что зафиксированная версия является той, которую команда намерена запускать.

После этого обновление зависимости становится видимым изменением репозитория: команда может проверить изменение commit, обсудить его и принять через обычный review. Lockfile помогает аудировать код actions и поддерживать согласованность зависимостей; сам по себе он не подтверждает безопасность выбранного кода.

Где заканчивается область фиксации?

Вызов reusable workflow внутри jobs.<job_id>.uses не фиксируется lockfile репозитория, который его вызывает. Зависимости reusable workflow относятся к репозиторию, где этот workflow определён. Чтобы закрепить сам вызов, укажите полный commit SHA; для фиксации его actions в исходном репозитории нужен собственный lockfile.

Lockfile контролирует код actions, но не другие входы сборки, например параметры, переданные action, секреты или образ runner. Он отвечает на конкретный вопрос: какой commit кода action будет выполнен? Эти остальные элементы требуют собственных правил управления.

Есть и особый случай — локальный action, вызванный через путь вроде uses: ./. По инструкции GitHub, расширение gh actions-lock не фиксирует и не анализирует локальный путь action. Если такой action использует другие actions, зависимостями нужно управлять отдельно; в документации описан вариант миграции ссылок на локальные actions в формат $/.

В результате одна запись lockfile может быть частью цепочки, но не заменяет контроль всех её звеньев. Для внешнего reusable workflow проверьте фиксацию вызова и состояние исходного репозитория; для локальных actions проверьте, как именно учтены их зависимости.

Как внедрить контроль без внезапных остановок CI?

GitHub рекомендует сначала провести пилот на выбранных репозиториях и workflow. Политика Require lockfile блокирует запуск целевых workflow без корректного lockfile, включая workflow без зависимостей uses:. Режим Evaluate для политик доступен только в GitHub Enterprise Cloud. Поэтому сначала подготовьте охват и автоматическое обновление, а затем включайте обязательное правило.

1. Проверьте исходные ссылки. Перед созданием lockfile убедитесь, что actions указывают на версии, которые команда действительно хочет закрепить. Генератор фиксирует commit, разрешённый из текущей ссылки.
2. Создайте и просмотрите lockfile. Установите расширение gh-actions-lock, запустите gh actions-lock из корня репозитория и просмотрите полный diff, включая переписанные ссылки uses.
3. Настройте актуализацию и проверку. Dependabot может обновлять соответствующие записи для уже подключённых workflow. В CI pull request можно настроить проверочную задачу с gh actions-lock --verify, чтобы обнаруживать устаревший lockfile до основной сборки.
4. Назначьте ревьюеров. Добавьте .github/workflows/actions.lock в CODEOWNERS и требуйте проверки изменений ответственными за безопасность сборки.
5. Проведите пилот политики. Начните с подключённых репозиториев и workflow. В Evaluate проанализируйте результаты; перед режимом Active проверьте, что все целевые workflow подготовлены и lockfiles остаются актуальными.

Require lockfile и отдельная политика Require actions to be pinned to a full-length commit SHA — разные правила; GitHub указывает, что их можно сохранять одновременно. Проверка в CI и обязательная политика также выполняют разные роли: первая обнаруживает устаревший файл во время работы над pull request, вторая блокирует запуск workflow, не соответствующего требованию.

Пример: обновление deployment action

Предположим, workflow публикует приложение через octo-org/deploy-action@v3. Сначала команда проверяет, какую версию разрешает эта ссылка, затем запускает gh actions-lock и рассматривает diff workflow вместе с записью commit в lockfile. При обновлении action проверяющий видит изменения ссылок и зафиксированного commit; это позволяет оценить конкретное обновление, а не полагаться на то, что подвижный тег всегда указывает на прежний код.

Если deployment выполняет reusable workflow из другого репозитория, локальный lockfile не охватывает его зависимости. Зафиксируйте ссылку на reusable workflow полным SHA и проверьте, что исходный репозиторий управляет собственными actions зависимостями. В больших организациях это превращает разрозненные правила в проверяемый процесс, сохраняя отдельный контроль параметров, секретов и runner.

Lockfile полезен как слой контроля кода actions: он делает версии и обновления обозримыми, включая транзитивные зависимости. Для надёжного охвата проверьте также reusable workflows и локальные actions, автоматизируйте актуализацию и вводите обязательную политику лишь после пилота.