Lockfile GitHub Actions фіксує код запуску, але не весь 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; це дає змогу оцінити конкретне оновлення, а не покладатися на те, що рухомий тег завжди вказуватиме на попередній код.

Якщо розгортання виконує reusable workflow з іншого репозиторію, локальний lockfile не охоплює його залежності. Закріпіть посилання на reusable workflow повним SHA і перевірте, що вихідний репозиторій керує власними залежностями actions. У великих організаціях це перетворює розрізнені правила на перевірюваний процес, залишаючи окремий контроль параметрів, секретів і runner.

Lockfile корисний як рівень контролю коду actions: він робить версії та оновлення прозорими, зокрема транзитивні залежності. Щоб забезпечити надійне охоплення, перевірте також reusable workflows і локальні actions, автоматизуйте оновлення та запроваджуйте обов’язкову політику лише після пілоту.