{"meta":{"title":"Применение зависимостей блокировки для зависимостей действий","intro":"Требовать зависимостей рабочих процессов в репозиториях и автоматически обновлять файлы.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/how-tos","title":"Инструкции"},{"href":"/ru/actions/how-tos/administer","title":"Администрирование"},{"href":"/ru/actions/how-tos/administer/enforce-workflow-lockfiles","title":"Принудительное применение файлов блокировки рабочего процесса"}],"documentType":"article"},"body":"# Применение зависимостей блокировки для зависимостей действий\n\nТребовать зависимостей рабочих процессов в репозиториях и автоматически обновлять файлы.\n\n> \\[!NOTE] Файлы блокировки зависимостей рабочего процесса находятся и подвергаются Публичный предварительный просмотр изменению.\n\nТребование блокировки обеспечивает согласованную, аудитируемую гарантию того, что каждый рабочий процесс выполняет проверенный код, не запрашивая у каждой команды принятие практики самостоятельно. Общие сведения см. в разделе [Блокировки зависимостей рабочего процесса](/ru/actions/concepts/security/workflow-dependency-lockfiles).\n\nЭто руководство поможет вам запустить пилотный проект в выбранных репозиториях и настроить автоматизацию для актуальности файлов блокировки. Если вы уверены, что файлы блокировки работают должным образом и не вводят трения разработчика, вы можете применить политику **\"Требовать блокировку\".**\n\n## Prerequisites\n\nПрежде чем применять файлы блокировки рабочих процессов и создавать процессы для их актуальности, в репозиториях должен существовать файл блокировки. Инструкции см. в разделе [Блокировка зависимостей действий в рабочих процессах репозитория](/ru/actions/how-tos/secure-your-work/lock-workflow-dependencies).\n\n## 1. Пилотируйте политику \"требовать блокировку\"\n\n> \\[!IMPORTANT]\n> **Режим оценки** политик доступен только в GitHub Enterprise. Не включите эту политику в **активном** режиме, пока вы не уверены, что у вас есть системы, чтобы обеспечить актуальность файла блокировки для всех целевых рабочих процессов.\n\nБлоки политики **\"Требовать блокировку\"** выполняются целевыми рабочими процессами, включающими зависимости действий, но **не** подключены к файлу блокировки репозитория. Сведения о настройке политики см. в разделе [Управление выполнением рабочих GitHub Actions процессов](/ru/actions/how-tos/administer/control-workflow-execution).\n\nЗапустите пилотный проект перед применением этой политики во всех репозиториях. Вы должны:\n\n* Область применения политики к определенным репозиториям, которые подключены к файлам блокировки.\n* Целевые рабочие процессы, которые были подключены к файлу блокировки. Это делается до тех пор, пока все рабочие процессы не будут подключены *, и* вы используете процессы, чтобы обеспечить автоматическое подключение новых рабочих процессов.\n* Начните с политики в режиме **оценки** и анализируйте результаты в разделе **\"Аналитика политик**\"\n\n## 2. Сохранение текущих файлов блокировки\n\nПринудительное применение работает только в том случае, если файлы блокировки остаются актуальными. Добавьте автоматизацию, чтобы разработчики не должны выполнять команду блокировки каждый раз, когда они создают или редактируют рабочие процессы.\n\nВ следующих разделах приведены примеры предотвращения устаревших блокировок в разных точках жизненного цикла разработки.\n\n* Оставьте файл в актуальном состоянии, включив Dependabot и создав рабочий процесс для выполнения команды блокировки.\n* Добавьте навык и перехватчик предварительной фиксации, чтобы сократить цикл обратной связи для разработчиков.\n\nГотовые к копированию реализации рабочего процесса и навыка см. в репозитории [gh-actions-lock](https://github.com/github/gh-actions-lock) .\n\n### Dependabot Обновления версий\n\nПри Dependabot ударе по версии действия он повторно создает соответствующую запись lockfile в том же запросе на вытягивание.\n\nВам не нужна какая-либо конфигурация, кроме Dependabot управления GitHub Actions зависимостями. См [. раздел AUTOTITLE](/ru/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/auto-update-actions).\n\nDependabot\n**не** будет подключить рабочий процесс, у который еще нет записей lockfile, поэтому этот параметр поддерживает покрытие, а не расширяет его.\n\n### Выделенный GitHub Actions рабочий процесс\n\nКогда кто-то добавляет или редактирует рабочий процесс, запустите другой рабочий процесс, который запускает команду блокировки. Активируйте рабочий процесс для изменений `.github/workflows/**` в любом `action.yml` или `action.yaml` файле, а затем предоставьте ему два задания:\n\n* Задание **обновления** , которое повторно создает файл блокировки при отправке и фиксирует результат. Для этого задания требуются `contents: write` разрешения, а правила защиты ветви или наборы правил должны разрешать GitHub Actions отправку в ветви, на которые она выполняется.\n* **Задание проверки**, которое выполняется `gh actions-lock --verify` при запросах на вытягивание. Это должно выйти из-за ошибки, если файл блокировки устарел, что делает его полезным для обязательной проверки.\n\n### Copilot Навык\n\nПри Copilot изменении файла рабочего процесса сообщите ему выполнить команду, чтобы обновить файл блокировки в том же наборе изменений.\n\nНавык должен сообщить Copilot повторно создать файл блокировки с помощью ИНТЕРФЕЙСА командной строки всякий раз, когда он изменяет рабочий процесс или локальное действие, и никогда не изменять файл блокировки напрямую. Он охватывает только изменения, сделанные с Copilotпомощью, поэтому рассматривать его как удобство, а не элемент управления. См [. раздел AUTOTITLE](/ru/copilot/concepts/agents/about-agent-skills).\n\n### Перехватчик предварительной фиксации\n\nЭто перехватывает устаревший файл блокировки до того, как фиксация существует, что является самым ранним отзывом разработчика.\n\nИспользуйте `gh actions-lock --verify-local --no-fix` в перехватчике. Он работает в автономном режиме, не нуждается в проверке подлинности и достаточно быстро, чтобы выполнить каждую фиксацию. Эта команда подтверждает, что каждая зависимость имеет запись lockfile, но не повторно проверяет пин-коды.GitHub\n\n## 3. Настройка процесса проверки изменений в файле блокировки\n\nБлокировка — это только элемент управления безопасностью, если кто-то считывает дифф. Измененная фиксация SHA сообщает, что код, который выполняется в рабочих процессах, изменился.\n\n1. Добавьте `.github/workflows/actions.lock` в `CODEOWNERS` файл, чтобы команда, отвечающая за безопасность сборки, автоматически запрашивала проверку. См [. раздел AUTOTITLE](/ru/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).\n2. Настройте правило защиты ветви или набор правил репозитория, чтобы требовать утверждения от владельца кода.\n3. Расскажите рецензентам, что искать. Инструкции см. в разделе [Блокировка зависимостей действий в рабочих процессах репозитория](/ru/actions/how-tos/secure-your-work/lock-workflow-dependencies#reviewing-lockfile-changes).\n\n## 4. Принудительное применение политики\n\nЕсли вы уверены, что файлы блокировки находятся на месте и будут оставаться актуальными, измените состояние применения политики **\"Требовать блокировку\"** на **\"Активный**\" и убедитесь, что все подключенные репозитории и рабочие процессы предназначены.\n\nОставьте проверку на шаге 2. Политика блокирует выполнение рабочего процесса без допустимого файла блокировки, но проверка проверки сообщает автору, что файл блокировки устарел, пока они по-прежнему работают над запросом на вытягивание."}