Блокировка зависимостей действий в рабочих процессах репозитория

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

1. Проверка ссылок на действия

Создание файла блокировки закрепляет зависимости для фиксаций на основе текущей ветви или ссылки на тег. Убедитесь, что они являются версиями, которые необходимо заблокировать.

Убедитесь, что каждая uses ссылка в рабочих процессах указывает на поддерживаемую текущую версию действия. Рекомендации см. в разделе Справочник по безопасному использованию.

Если любой из рабочих процессов вызывает повторно используемый рабочий процесс в другом репозитории, проверьте эти ссылки. Зависимости повторно используемых рабочих процессов охватываются файлом блокировки репозитория, в котором определен повторно используемый рабочий процесс. Если ваша организация поддерживает общие рабочие процессы, рекомендуется сначала подключить эти репозитории. См . раздел AUTOTITLE.

Рекомендуется управлять DependabotGitHub Actions зависимостями. Если он еще не включен, включите его перед созданием файла блокировки. См . раздел AUTOTITLE.

2. Установка actions-lock расширения

1. GitHub CLI Установите .

2. Установите расширение.

   Bash

   gh extension install github/gh-actions-lock
   

3. Создание файла блокировки

В корне репозитория запустите расширение без аргументов. Он сканирует каждый рабочий процесс в разделе .github/workflows/, закрепляет каждое разрешаемое действие для фиксации SHA и записывает файл блокировки.

gh actions-lock

gh actions-lock

Чтобы подключить один рабочий процесс вместо всего каталога, передайте путь.

gh actions-lock .github/workflows/ci.yml

gh actions-lock .github/workflows/ci.yml

Если расширение сообщает о том, что он пропустил рабочий процесс, так как действия локального пути не поддерживаются, это означает uses: ./… , что ссылка в этом рабочем процессе не разрешена в реальный файл действия. Локальные пути разрешаются из корневого каталога репозитория, а не из каталога файла, содержащего их, поэтому путь, который выглядит рядом с собственным файлом, может не разрешаться. Исправьте путь и снова выполните команду.

Для полного набора параметров выполните команду gh actions-lock --help.

4. Просмотрите изменения и фиксацию

Расширение изменяется больше, чем файл блокировки, поэтому перед фиксацией просмотрите полный дифф. Он также перезаписывает ссылки на рабочий процесс uses на определенную версию, разрешенную, поэтому ссылка, например octo-org/deploy-action@v3 , может стать octo-org/deploy-action@v3.1.0. Это делает ссылку более конкретной, не изменяя фиксацию, на который она разрешается.

Если репозиторий, организация или предприятие разрешает только указанные действия, проверьте список разрешений перед фиксацией. После подключения рабочего процесса список разрешений проверяется на заблокированные shas фиксации, так как тег можно переместить в другой код, но заблокированный SHA не может. Записи, закрепленные к тегу, например actions/checkout@v6, больше не соответствуют. Вместо этого используйте подстановочный знак или полную фиксацию SHA. См . раздел AUTOTITLE.

Ссылки на действия в собственном репозитории также перезаписываются из uses: ./… эквивалента uses: $/…как в рабочих процессах, так и в файлах в репозитории action.yml . Ссылка $/… всегда разрешает выполнение фиксации, поэтому она изначально закреплена и не требует записи блокировки.

5. Сохранение текущего файла блокировки

Сохраняйте блокировку в актуальном состоянии с помощью файлов рабочих процессов репозитория и обновлений системы безопасности.

1. Повторно запустите расширение при изменении зависимостей. Запустите gh actions-lock снова при добавлении рабочего процесса с uses зависимостями или добавления или удаления uses зависимостей в существующем рабочем процессе.

2. Позвольте Dependabot обрабатывать удары версий. При Dependabot открытии обновления версии для действия в подключенном рабочем процессе он также повторно создаст соответствующую запись lockfile в том же запросе на вытягивание, чтобы файл рабочего процесса и блокировка не могли дрейфовать друг от друга.

Dependabot Не будет подключен рабочий процесс для вас. Если он ударит зависимостью в рабочем процессе без записи lockfile, он просто сообщает, что подключение требуется.

1. Повторно разрешать ссылки, перемещенные. Ссылки на ветви или частичные версии, такие как main или v3, являются доверенными из файла блокировки и не разрешаются повторно при обычном запуске. Если расширение сообщает об ошибке, так как тег теперь указывает на другую восходящую фиксацию, сначала проверьте журнал вышестоящего репозитория. Если перемещение было законным, повторно устраните ссылку с gh actions-lock --relockпомощью . Если фиксация, изначально заблокированная, больше недоступна, например из-за принудительной отправки или удаления вышестоящего репозитория, --relock по-прежнему сообщит об ошибке. Чтобы принять новую фиксацию, выполните команду gh actions-lock --relock --accept-moved.

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

Просмотрите изменения в файле блокировки, как и любые другие изменения зависимостей:

• Изменено commit — это код, который будут выполняться рабочие процессы. Обработайте его так, как вы будете относиться к любой другой версии зависимости.
• Изменение owner_id или repo_id должно быть редким. Это означает, что репозиторий за этим именем не является изначально заблокированным, поэтому следует изучить перед слиянием.

Если файл блокировки выглядит неправильно, исправьте файлы рабочего процесса и повторно создайте его. Никогда не редактируйте файл блокировки вручную.

Дальнейшие действия

Создав файл блокировки для репозитория, убедитесь, что он применяется и обновлен без необходимости выполнения команд разработчиками. См . раздел AUTOTITLE.