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

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

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

Prerequisites

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

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

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

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

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

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

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

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

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

Готовые к копированию реализации рабочего процесса и навыка см. в репозитории gh-actions-lock .

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

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

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

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

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

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

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

Copilot Навык

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

Навык должен сообщить Copilot повторно создать файл блокировки с помощью ИНТЕРФЕЙСА командной строки всякий раз, когда он изменяет рабочий процесс или локальное действие, и никогда не изменять файл блокировки напрямую. Он охватывает только изменения, сделанные с Copilotпомощью, поэтому рассматривать его как удобство, а не элемент управления. См . раздел AUTOTITLE.

Перехватчик предварительной фиксации

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

Используйте gh actions-lock --verify-local --no-fix в перехватчике. Он работает в автономном режиме, не нуждается в проверке подлинности и достаточно быстро, чтобы выполнить каждую фиксацию. Эта команда подтверждает, что каждая зависимость имеет запись lockfile, но не повторно проверяет пин-коды.GitHub

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

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

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

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

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

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