Lockfile для Actions стал общедоступным: что доказывает зелёная проверка
В PR версия uses может остаться прежней, а код за ней — измениться: тег способен указывать на другой коммит. GitHub объявил общую доступность lockfile 28 октября. После предварительной версии полезно разобраться, какие именно доказательства дают разные проверки.
Понятные ссылки и записанные коммиты
.github/workflows/actions.lock связывает ссылки на actions с исполняемыми коммитами. Файл создаёт gh actions-lock; поддерживаются Free, Team и GitHub Enterprise Cloud, включая размещение данных по регионам. Workflow можно подключать по одному. Сгенерированный файл проверяют вместе с изменениями workflow, а не собирают вручную.
В условном примере demo/build@v1 сначала указывает на A, затем на B. Разрешение одной ссылки может выбрать другой код при следующем запуске; lockfile сохраняет записанный коммит. Рисунок не является реальным тестом. Если коммит больше недостижим из записанного upstream-тега или ветки, запуск может его отклонить.
Что подтверждает офлайн-проверка?
gh actions-lock --verify-local без сети проверяет покрытие: есть ли записи для uses. Это удобно перед коммитом, но не подтверждает происхождение. gh actions-lock --verify проверяет его онлайн, а runner повторяет проверку при старте задания. Два зелёных результата имеют разный смысл.
Если параллельный PR добавил action без обновления lockfile, локальная проверка может обнаружить пропуск. Полнота записей не доказывает ни происхождение, ни безопасность кода. Второй рисунок обобщает документацию; для статьи CLI не устанавливался и не запускался.
У повторно используемых workflow своя граница
Транзитивные зависимости actions учитываются, но вызовы через jobs.<job_id>.uses lockfile не закрепляет. Для них нужен полный SHA коммита. Внутренние actions подчиняются lockfile репозитория, где workflow определён, а не вызывающего репозитория.
Допустим, приложение вызывает deployment из платформенного репозитория. Один actions.lock приложения не показывает закрепление actions платформы. Нужно сопоставить SHA вызова и зависимости платформы. Образ runner, входные параметры и secrets остаются отдельными входами: закрепление action не замораживает всю среду.
В PR обновления читайте оба файла
При обновлении action подключённого workflow Dependabot заново создаёт соответствующую запись в том же PR. Так читаемая версия сопоставляется с реальным коммитом. --relock обновляет переместившиеся ссылки и записывает файлы; это другой режим, не проверка только для чтения. Ревью кода по-прежнему необходимо.
Require lockfile позволяет обязать использовать механизм, но не стирает границы репозиториев. Один workflow помогает освоить генерацию, ревью и онлайн-валидацию. Следующий зелёный значок стоит читать точно: он подтверждает покрытие, происхождение или проверку выбранного кода человеком?