Почему зависимости рабочих процессов блокируются?
Рабочие процессы часто ссылались на действие тегом или ветвью, например uses: octo-org/deploy-action@v3 или uses: octo-org/deploy-action@main.
GitHub Actions разрешает эту ссылку на то, что зафиксирует тег или ветвь во время выполнения.
Теги и ветви могут перемещаться. В результате код, который выполняется, не гарантируется, что код, который автор рабочего процесса первоначально проверил. Если учетная запись вышестоящего обработчика скомпрометирована, а тег переназначается, репозитории могут запускать вредоносный код.
Файл блокировки зависимостей рабочего процесса закрепляет sha фиксации для каждого действия, от которых зависят рабочие процессы, включая транзитивные зависимости. Он не закрепляет вызовы повторно используемых рабочих процессов (jobs.<job_id>.uses). Чтобы закрепить повторно используемый рабочий процесс, сослаться на него с помощью полной фиксации SHA. Lockfile определяет, какой код действия выполняется в средстве выполнения. Он не управляет другими входными данными сборки, такими как входные параметры, секреты или образ средства выполнения. Файл блокировки предоставляет следующие сведения для кода действия, который он охватывает:
- Воспроизводимое разрешение зависимостей действий
- Просмотр изменений зависимостей и Dependabot обновлений версий
- Аудит зависимостей действий систем CI/CD
Как работает блокировка?
Файл блокировки определяется в репозитории по адресу .github/workflows/actions.lock. Он создается расширением gh actions-lockGitHub CLI и никогда не должен изменяться вручную.
Рабочие процессы репозитория можно подключить к файлу блокировки один раз или одновременно. После подключения рабочего процесса:
- Все зависимости действий, которые использует рабочий процесс, должны присутствовать в файле блокировки.
- Заблокированная фиксация — это то, что выполняется при выполнении рабочего процесса, а также то, какие политики разрешенных действий проверяются.
- Эта фиксация должна быть доступной из ветви или тега, записанного для него в файле блокировки, в собственном репозитории действия. Фиксация, которая существует только в вилке, или она больше не доступна из этой ветви или тега, отклоняется при запуске рабочего процесса.
Файл блокировки охватывает рабочие процессы в собственном репозитории, включая транзитивные зависимости (действия, используемые зависимостями действия ), за исключением зависимостей повторно используемых рабочих процессов. Повторно используемые рабочие процессы также могут иметь собственные файлы блокировки. Зависимости многократно используемых рабочих процессов охватываются файлом блокировки репозитория, в котором он определен, а не с помощью файла блокировки репозитория, вызывающего его.
Что такое запись lockfile?
В файле блокировки есть два раздела.
workflows записывает зависимости каждого подключенного рабочего процесса и dependencies записывает записи, в которых фиксируется каждая из этих ссылок.
# This file is machine-generated by `gh actions-lock`.
# Do not edit by hand; run `gh actions-lock` to update.
# Docs: https://gh.io/actions-lockfile
version: 'v0.0.3'
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 использует их для подтверждения во время выполнения, что репозиторий за именем по-прежнему заблокирован.
Этот структурированный формат предоставляет такие средства, как Dependabot записывание, доступное для машинного чтения, которые можно использовать для управления обновлениями зависимостей, без использования комментариев YAML в качестве заметок версий.
Как файлы блокировки сравниваются с закреплением SHA?
GitHub в файлах рабочего процесса рекомендуется закреплять сторонние действия с полной фиксацией SHA в файлах рабочего процесса. Для репозиториев, которые принимают блокировку, SHA закрепление в файлах рабочих процессов больше не требуется. Файл блокировки является лучшим вариантом, так как он:
- Поддерживает транзитивные зависимости
- Упрощает чтение файлов рабочих процессов
- Записывает удостоверение исходного репозитория
Файл блокировки также удовлетворяет отдельным действиям, которые необходимо закрепить в политике SHA полной длины фиксации для рабочих процессов, подключенных к нему. См . раздел AUTOTITLE.
Дальнейшие действия
Сведения о создании файла блокировки для репозитория см. в разделе Блокировка зависимостей действий в рабочих процессах репозитория.