Skip to main content
Skip to content

Применение зависимостей блокировки для зависимостей действий

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

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

Repository administrators, organization owners, and enterprise owners

GitHub Enterprise Cloud

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

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

Prerequisites

Прежде чем применять файлы блокировки рабочих процессов и создавать процессы для их актуальности, в репозиториях должен существовать файл блокировки. Инструкции см. в разделе Блокировка зависимостей действий в рабочих процессах репозитория. Вам не нужно быть администратором для создания файла блокировки. Любой пользователь с доступом на запись в репозиторий может сделать это, чтобы можно было делегировать подключение к отдельным командам, прежде чем применять политику централизованно.

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

1. Пилотируйте политику "Требовать блокировку"

Внимание

Режим оценки политик доступен только в GitHub Enterprise Cloud. Не включите эту политику в активном режиме, пока вы не уверены, что у вас есть системы, чтобы обеспечить актуальность файла блокировки для всех целевых рабочих процессов.

Блоки политики "Требовать блокировку" выполняются целевыми рабочими процессами, которые не подключены к файлу блокировки репозитория, включая рабочие процессы без uses: зависимостей.

Запустите пилотный проект перед применением этой политики во всех репозиториях. Вы должны:

  • Область применения политики к определенным репозиториям, которые подключены к файлам блокировки.
  • Нацеливать определенные рабочие процессы, которые были подключены к файлу блокировки, пока все рабочие процессы не будут подключены, и у вас есть автоматизированные процессы для подключения новых.
  • Начните с политики в режиме оценки и анализируйте результаты в разделе "Аналитика политик".

Требовать блокировку — это отдельная политика от "Требовать действия", которые необходимо закрепить на полной длине фиксации SHA. Вы можете включить оба варианта во время развертывания. Сведения о настройке политики и их взаимодействии см. в разделе Управление выполнением рабочих GitHub Actions процессов.

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

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

В следующих разделах приведены примеры предотвращения устаревших файлов блокировки в различных точках жизненного цикла разработки:

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

Dependabot Обновления версий

При Dependabot ударе по версии действия он повторно создает соответствующую запись lockfile в том же запросе на вытягивание.

Вам не нужна какая-либо конфигурация, кроме Dependabot управления GitHub Actions зависимостями. См . раздел AUTOTITLE.

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

Выделенный рабочий процесс или Copilot

Когда кто-то добавляет или редактирует рабочий процесс, запустите другой рабочий процесс, который запускает команду блокировки. Активируйте рабочий процесс для изменений .github/workflows/** в любом action.yml или action.yaml файле, а затем предоставьте ему два задания:

  • Задание обновления , которое повторно создает файл блокировки при отправке и фиксирует результат. Для этого задания требуются contents: write разрешения, а правила защиты ветви или наборы правил должны разрешать GitHub Actions отправку в ветви рабочего процесса. Для записи в файл блокировки требуется workflow область OAuth, поэтому убедитесь, что средство имеет эту область.
  • Задание проверки, которое выполняется gh actions-lock --verify при запросах на вытягивание. Это должно выйти из-за ошибки, если файл блокировки устарел, что делает его полезным для обязательной проверки.

Пример рабочего процесса, готового к использованию, см. в verify-lockfile.yml в репозитории gh-actions-lock . Если вы используете Copilot для редактирования рабочих процессов, его также можно настроить для повторного создания файла блокировки в том же наборе изменений. См. навык блокировки gh-actions и Навыки агента.

3. Настройка процесса проверки изменений в файле блокировки

Блокировка — это только элемент управления безопасностью, если кто-то считывает дифф. Измененная фиксация SHA, в частности, сообщает, что код, выполняемый рабочими процессами, изменился.

  1. Добавьте .github/workflows/actions.lock в CODEOWNERS файл, чтобы команда, отвечающая за безопасность сборки, автоматически запрашивала проверку. См . раздел AUTOTITLE.
  2. Настройте правило защиты ветви или набор правил репозитория, чтобы требовать утверждения от владельца кода.
  3. Расскажите рецензентам, что искать. Инструкции см. в разделе Блокировка зависимостей действий в рабочих процессах репозитория.

4. Принудительное применение политики

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

Внимание

Если требуется блокировка****активна, каждый целевой рабочий процесс, который не подключен к файлу блокировки репозитория, блокируется, даже если другие рабочие процессы в том же репозитории подключены. Перед активацией политики запустите gh actions-lock --verify в каждом целевом репозитории или просмотрите аналитические сведения о политике в режиме оценки , чтобы убедиться, что каждый целевой рабочий процесс охватывается.

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

Если проверка проверки завершается ошибкой, ознакомьтесь с руководством по устранению неполадок с блокировкой gh-actions в репозитории gh-actions-lock .