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

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

Кто может использовать эту функцию?

People with write access to a repository

GitHub Enterprise Cloud

В этой статье

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

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

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

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

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

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

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

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

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

    Bash
    gh extension install github/gh-actions-lock

Совет

Чтобы обновить расширение позже, выполните команду gh extension upgrade gh-actions-lock.

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

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

Bash
gh actions-lock

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

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

Расширение никогда не следует или блокирует действие локального пути (uses: ./…). ./ Путь выполняет все, что извлечено в рабочей области runner, поэтому расширение не может закрепить его или увидеть, что он использует. $/ Путь запускает собственное действие репозитория при фиксации рабочего процесса, поэтому он закреплен и действия, которые он использует, могут быть заблокированы. Сравнение двух см. в разделе Синтаксис рабочего процесса для GitHub Actions.

Если локальное действие в вашем извлечении использует другие действия, расширение сообщает local-action об ошибке и ничего не записывает, так как эти действия завершаются сбоем во время выполнения без записей блокировки. Чтобы заблокировать локальное действие в качестве ссылки на тот же репозиторий, выполните следующую команду:

Bash
gh actions-lock --migrate-local-actions

Чтобы сохранить ссылку и сообщить о ней ./ как предупреждение, передайте --ignore-local-actions. См. раздел "Сохранение локального пути".

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

Сохранение действия локального пути

Если вы передаете --ignore-local-actions, то, что происходит во время выполнения, зависит от действий, которые использует локальное действие:

  • В нем не используются другие действия, например только run: шаги: рабочий процесс выполняется нормально.
  • В нем используются действия, имеющие записи блокировки для одного рабочего процесса: рабочий процесс выполняется нормально.
  • В нем используется действие, которое не содержит записи блокировки для этого рабочего процесса: задание завершается ошибкой при достижении шага локального действия, например lockfile missing pin for octo-org/setup-tool@v2.0.0. Предыдущие шаги уже выполняются.

Вместо этого рекомендуется --migrate-local-actions использовать действие в качестве закрепленной $/ ссылки. Если необходимо сохранить ссылку ./ , предоставьте записи файла блокировки рабочего процесса для действий, которые использует локальное действие. Добавьте составное действие, которое использует те же действия, с теми же ссылками и вызовите его из рабочего процесса на шаге, который никогда не выполняется. Затем выполните команду gh actions-lock --ignore-local-actions.

# .github/actions/lock-local-deps/action.yml
name: Lock local action dependencies
description: Never runs. Lists the actions that ./.github/actions/build uses.
runs:
  using: composite
  steps:
    - uses: octo-org/setup-tool@v2.0.0

# In the workflow
steps:
  - uses: actions/checkout@v6
  - if: false
    uses: $/.github/actions/lock-local-deps
  - uses: ./.github/actions/build

Записи должны записываться для одного рабочего процесса. Запись, записанная только для другого рабочего процесса, не учитывается. При изменении зависимостей локального действия обновите составное действие и снова запустите его gh actions-lock --ignore-local-actions .

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

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

Внимание

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

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

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

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

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

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

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

  1. Повторно разрешать ссылки, перемещенные. Как расширение обрабатывает перемещаемую ссылку, зависит от ссылки:

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

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

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

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

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

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

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