Почему вчерашняя сборка может запустить другой код
Вы сделали сайт с ИИ. При отправке изменений GitHub автоматически проверяет проект и готовит его к выпуску. Это GitHub Actions, система выполнения заданных шагов. Всю такую последовательность называют workflow, рабочим процессом, Для готового внешнего шага используют слово action, действие.
Свою последовательность вы храните в проекте, но часть её работы часто выполняют чужие готовые компоненты. Ссылка на такой компонент может указывать на метку версии, короткое имя вроде v4. Если автор передвинет метку, это имя останется прежним, а код под ним изменится.
Именно это меняют новые lockfiles, файлы фиксации. Они позволяют оставить удобную ссылку в описании процесса, но выполнять выбранную точную версию. Как устроен весь путь от правки до сайта, объясняем в уроке про CI/CD и деплой.
Что представил GitHub
По объявлению GitHub от 14 октября workflow lockfiles вышли в открытое тестирование для планов Free, Team, Enterprise Cloud и Enterprise Cloud with data residency. Это ещё не окончательный выпуск функции.
Файл .github/workflows/actions.lock хранит выбранные коммиты, точные сохранённые версии кода. В него попадают действия, их дальнейшие зависимости и переиспользуемые процессы. Подключать фиксацию можно постепенно, для отдельных процессов.
Для подключённого процесса GitHub требует записи о зависимостях и запускает закреплённые коммиты. Если метка или ветка снаружи сдвинулась, запуск всё равно использует выбранный код. Ветка служит отдельной линией изменений проекта; её содержимое тоже может меняться.
Для вызванного переиспользуемого процесса действуют записи из его собственного репозитория. Внешний файл фиксации не охватывает автоматически все зависимости внутри такого процесса.
В документации GitHub описан порядок подключения. Файл создают и обслуживают расширением gh actions-lock для GitHub CLI. CLI расшифровывается как Command-Line Interface, интерфейс командной строки: программа, которой дают текстовые команды в терминале.
Чем это полезно человеку, который пишет с ИИ
Представьте учебную ситуацию: вы сравниваете два запуска своего неизменного кода. Поведение внешнего шага изменилось. Фиксация защищает от одной из причин такой неожиданности: перехода к другому коду под тем же именем.
Это помогает и при разборе чужой настройки, которую предложил ИИ. Теперь вопрос звучит конкретнее: «Какие внешние шаги использует наша сборка и какие их версии фактически запустятся?» Уверенное «я настроил автоматическую выкладку» на него не отвечает.
Но закреплённый опасный компонент останется опасным. Файл не проверяет его намерения, не исправляет уязвимости и не делает весь выпуск безопасным. Сначала нужно понять, что запускается и какие права этому выданы. Если сборка ломается, ищите причину по её фактическому результату. Наличие нового файла само по себе о результате не говорит.
С чего начать без переделки выпуска
Попросите своего помощника показать один существующий workflow и объяснить внешние действия в нём. Затем выясните, используются ли движущиеся метки или уже закреплены точные версии. Только после этого обсуждайте подключение новой функции в отдельной ветке проекта.
Dependabot, встроенный помощник GitHub по обновлению зависимостей, умеет обновлять соответствующую запись lockfile в том же предложении правки. Обновление всё равно нужно просмотреть и проверить. Созданный файл нужно обслуживать: следить за обновлениями и проверять их.
Мы сверили объявление и документацию. На рабочем выпуске портала функцию пока не включали.
