GitHub Actions: workflow lockfiles

Источники проверены 15 октября 2026 года (Екатеринбург, UTC+5). Это рецепт для отдельного пилота, не выполненное включение защиты в SEO Recipes. Рабочие workflows, политики, secrets и зависимости репозитория при подготовке не изменялись.

Что появилось и кому доступно

Анонс от 14 октября описывает public preview фиксации зависимостей Actions в .github/workflows/actions.lock. В исправленной редакции анонса перечислены Free, Team и Enterprise Cloud, включая data residency. Некоторые страницы GitHub Docs всё ещё показывают только Enterprise Cloud; это расхождение источников, а не установленная недоступность функции на Free. Проверяйте поддержку нужного аккаунта перед внедрением. GHES не поддерживается согласно README расширения.

Lockfile не делает выбранную зависимость безопасной: сначала ревью кода, затем фиксация. Формат и флаги пока могут меняться. Записывайте версию gh, версию расширения и дату проверки; успешная установка CLI не доказывает применение защиты сервером.

Границы механизма

По документации модели, lockfile хранит соответствие workflows и зависимостей, точные коммиты и идентификаторы владельца/репозитория. Он создаётся генератором, не вручную. Запись распространяется на подключённые workflows данного репозитория и вложенные action-зависимости.

Вызов reusable workflow и его внутренние зависимости — разные уровни: вызываемый workflow фиксируется как ссылка, а его внутренние зависимости обслуживает lockfile репозитория, в котором он определён. Нельзя считать lockfile вызывающей стороны защитой всей чужой цепочки.

Shell-команды run, загрузки внешних скриптов, npm-зависимости, секреты и содержимое образов требуют отдельных мер. В частности, actions.lock не заменяет package-lock.json, минимальные permissions и проверку непроверенного ввода.

Пилот на примере SEO Recipes

В проверенном main (5340451798f27dcd2b1bc4ff41fa60b59a65ee10) есть два workflow: codecov.yml с actions/checkout@v3 и codecov/codecov-action@v3, а также mirror.yml с checkout и shell-публикацией зеркала. Это описание исходников, не рекомендация использовать старые major-версии. Перед фиксацией проверьте поддерживаемость действий отдельно.

Начните с учебной копии и одного workflow без реальных публикаций. Для SEO Recipes не запускайте mirror как smoke-test: его shell-шаг выполняет запись во внешнее зеркало. В этом рецепте демонстрируется локальная генерация, не запуск workflow.

Подготовка CLI

Сначала изучите официальное расширение, затем установите его в своей среде:

gh --version
gh extension install github/gh-actions-lock
gh extension list
gh actions-lock --help

Для сетевых проверок нужен авторизованный gh с чтением необходимых репозиториев. Не вставляйте токен в пример, URL или публичный лог. Не добавляйте широкие права только для генерации lockfile.

Генерация для одного workflow

Команды ниже выполняются из корня чистой рабочей копии. Они меняют локальные файлы и индекс, но не делают commit/push и не запускают CI:

set -eu
git rev-parse --show-toplevel >/dev/null
test -z "$(git status --porcelain)" || {
  printf '%s\n' 'Use a clean working tree for the pilot.' >&2
  exit 1
}
git switch -c chore/workflow-lockfile-pilot
gh actions-lock .github/workflows/codecov.yml
git add -N .github/workflows/actions.lock
git status --short
git diff --check
git diff

git add -N позволяет увидеть новый файл в diff. Не продолжайте при ошибке генератора. По инструкции GitHub, генератор может менять uses и локальные action.yml, поэтому просматривайте весь diff, не только actions.lock. Ссылки ./… могут преобразовываться в $/…; пропущенный workflow нельзя считать подключённым.

Проверьте охват выбранного workflow, коммиты, владельцев и отсутствие незапланированных изменений. Для вызова чужого reusable workflow отдельно проверьте его репозиторий. При action allowlist проверьте разрешение зафиксированного SHA: правило только по тегу может больше не совпасть. Не расширяйте allowlist вслепую ради зелёного запуска.

Проверка без изменения файлов

gh actions-lock --verify-local
gh actions-lock --verify

Согласно README CLI, первая команда работает офлайн и проверяет наличие записей; она не подтверждает доверенность upstream-коммитов. Вторая выполняет сетевую проверку pins без записи. Ошибка требует расследования, а не автоматического принятия нового SHA.

Обычный запуск сохраняет существующие pins. Обновление легитимно переместившихся ссылок выполняют через --relock после ревью upstream. Не добавляйте --accept-moved в автоматическое исправление CI: этот флаг разрешает принять замену даже при недоступности прежнего коммита.

Обновления и контроль внедрения

Анонс и документация описывают обновление lockfile вместе с version update Actions от Dependabot для уже подключённого workflow. Это не автоматическое подключение всех workflow и не причина объединять Dependabot PR без проверки diff.

Перед обязательной политикой выполните изолированный тест: корректный workflow проходит; добавленная без перегенерации зависимость обнаруживается; ошибка не обходится расширением permissions; после регенерации проходит только согласованное изменение. Это план теста, не полученные результаты.

Руководство по enforcement предлагает сначала ограниченный пилот. Evaluate mode доступен только GitHub Enterprise. Не включайте Require lockfile в Active для неподготовленных workflow. Для проверки обновлений в PR отдельный workflow также должен соответствовать выбранной политике; его конфигурация здесь не внедряется.

Проверки этого рецепта

Команды сопоставлены с официальной документацией и README. Три Bash-блока прошли проверку синтаксиса, но CLI, серверное enforcement и отрицательные CI-сценарии в этом запуске не выполнялись: рабочая среда не разрешает имя GitHub. Нет сгенерированного «для вида» actions.lock и придуманных commit SHA. Полная сборка сайта оценивается отдельно от работоспособности описанного механизма.

• Раздел хостинга
• Практические проверки