# Блокировки зависимостей рабочего процесса

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

> \[!NOTE] Файлы блокировки зависимостей рабочего процесса находятся и подвергаются Публичный предварительный просмотр изменению.

## Почему зависимости рабочих процессов блокируются?

Когда рабочий процесс ссылается на действие тегом или ветвью, например `uses: octo-org/deploy-action@v3` или `uses: octo-org/deploy-action@main`, GitHub Actions разрешает эту ссылку на то, что зафиксирует тег или ветвь во время выполнения.

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

Файл блокировки зависимостей рабочего процесса закрепляет sha фиксации для каждого действия (включая транзитивные зависимости) и повторно используемый рабочий процесс, от которых зависят рабочие процессы. Это дает вам следующее:

* Воспроизводимые сборки
* Просмотр изменений зависимостей и Dependabot обновлений версий
* Аудит зависимостей систем CI/CD

## Как работает блокировка?

Файл блокировки определяется в репозитории по адресу `.github/workflows/actions.lock`. Он создается расширением `gh actions-lock`GitHub CLI и никогда не должен изменяться вручную.

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

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

Файл блокировки охватывает рабочие процессы в собственном репозитории. Он распространяется на транзитивные зависимости (действия, используемые *зависимостями действия* ), **за исключением** зависимостей повторно используемых вызовов рабочих процессов. Повторно используемый рабочий процесс охватывается блокировкой репозитория, в котором он определен.

## Что такое запись lockfile?

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

```yaml
# This file is machine-generated by `gh actions-lock`.
# Do not edit by hand; run `gh actions-lock` to update.
version: 'v0.0.2'
workflows:
    '.github/workflows/ci.yml':
        - 'octo-org/deploy-action@v3.1.0'
dependencies:
    'octo-org/deploy-action@v3.1.0':
        ref: 'v3.1.0'
        commit: 'sha1-...'
        owner_id: 44036562
        repo_id: 197814629
```

Каждая запись зависимостей:

* **`ref`**: ссылка на рабочий процесс используется, например тег или ветвь.
* **`commit`**: точная фиксация ссылки, разрешенной. Это код, который будет выполняться.
* **`owner_id` и `repo_id`**: числовое удостоверение исходного репозитория. GitHub Actions использует их для подтверждения во время выполнения, что репозиторий за именем по-прежнему заблокирован.

## Как файлы блокировки сравниваются с закреплением SHA?

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

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

Сведения о создании файла блокировки для репозитория см. в разделе [Блокировка зависимостей действий в рабочих процессах репозитория](/ru/actions/how-tos/secure-your-work/lock-workflow-dependencies).