14 октября GitHub объявил публичную предварительную версию lockfiles для Actions. Они помогают зафиксировать код сторонних шагов автоматизации, даже когда в сценарии остаётся ссылка на знакомый тег или ветку. Это полезно для сборок, которые должны запускать проверенные версии зависимостей.

Зачем фиксировать тег

Учебный пример: сценарий использует action по тегу v3. Владелец action перенёс этот тег на другой коммит. Файл сценария в вашем репозитории остался прежним, но следующий запуск может получить обновлённый код.

Lockfile связывает такую ссылку с конкретным коммитом. После подключения сценария GitHub Actions использует записанный коммит, даже если тег или ветка переместились.

Что попадает в файл

Файл называется .github/workflows/actions.lock. Он хранит связи сценариев с зависимостями и точные коммиты этих зависимостей. В нём также записывается идентичность исходного репозитория, чтобы проверить, что за прежним именем остался тот же источник.

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

Как пробовать

Для генерации используется расширение GitHub CLI с командой gh actions-lock. Можно начать с одного сценария. Перед коммитом нужно просмотреть весь diff: расширение меняет lockfile и ссылки uses в сценариях. Сам lockfile вручную не редактируют.

После подключения все требуемые action-зависимости сценария должны быть учтены. При обновлении версии action через Dependabot соответствующая запись lockfile обновляется в том же pull request. Подключать новые сценарии к фиксации всё равно нужно отдельно.

Границы предварительной версии

В обновлённом анонсе 14 октября перечислены Free, Team и варианты Enterprise Cloud, включая data residency. При этом страница инструкции пока указывает только Enterprise Cloud. Перед внедрением стоит проверить доступность для своего репозитория. GitHub Enterprise Server расширение сейчас не поддерживает; формат и поведение preview могут меняться.

Фиксация коммита не подтверждает безопасность его содержимого. Проверка самой зависимости остаётся отдельной задачей. Результат сборки также зависит от среды runner: GitHub, например, еженедельно обновляет предустановленные инструменты своих образов. Поэтому один lockfile не гарантирует одинаковый результат всей сборки.

Я бы начал с одного некритичного сценария, проверил изменения зависимостей и выполнил обычные проверки сборки. Так проще оценить влияние preview на рабочий процесс.

Источники: GitHub Changelog от 14 октября, GitHub Docs и официальный репозиторий расширения.

Как вы сейчас отслеживаете изменения сторонних шагов в своих сборках?

#Разработка #Автоматизация #GitHubActions