Docker-экшены: полный контроль окружения ценой только-Linux и накладных образа

Полный контроль окружения

Когда composite- и JavaScript-экшены не справляются — потому что тебе нужен cosign, конкретный glibc или скомпилированный бинарь без npm-эквивалента — Docker-экшен не костыль: это единственный тип, созданный владеть всем своим окружением. Вопрос не в том, достаточно ли он мощный; вопрос в том, оправдана ли цена для твоего случая.

Docker-экшен объявляет runs.using: "docker" и либо image: "Dockerfile" (собирается на раннере), либо image: "docker://ghcr.io/org/img:tag" (тянется пресобранным). Внутри контейнера вы контролируете всё — базовую ОС, системные библиотеки, любой языковой рантайм, точные версии инструментов — что не могут дать composite- и JavaScript-экшены. Если вашему экшену нужен cosign, конкретный glibc, скомпилированный бинарь Go или Rust или инструмент без npm-эквивалента, контейнер — единственный тип, упаковывающий это воспроизводимо:

FROM alpine:3.20
RUN apk add --no-cache cosign skopeo
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

# action.yml
runs:
  using: "docker"
  image: "Dockerfile"
  args:
    - ${{ inputs.tag }}
  env:
    REGISTRY_TOKEN: ${{ inputs.token }}

Контракт рантайма отличается от JavaScript-экшена. Inputs приходят как переменные окружения INPUT_* в контейнере (input tag становится INPUT_TAG), и их можно также передать позиционно через args:. Outputs пишутся дозаписью в файл, названный $GITHUB_OUTPUT — echo "result=ok" >> "$GITHUB_OUTPUT" изнутри entrypoint — а рабочий каталог bind-монтируется в $GITHUB_WORKSPACE. Никакого toolkit; вы говорите на протоколе напрямую через env-переменные и эти файлы.

Цена: только-Linux и накладные образа

У силы контейнера две цены, обе платятся на каждом прогоне. Первая: Docker-экшены работают только на Linux-раннерах — не macOS, не Windows. Экшен, что вы хотите пригодным везде, не может быть Docker-экшеном; одно это толкает многие переиспользуемые экшены к JavaScript. Вторая: контейнер должен материализоваться до запуска вашего кода. С image: "Dockerfile" раннер собирает образ на каждом вызове, если слои не закэшированы — обычно 40-90 секунд. С image: "docker://..." он тянет пресобранный образ — быстрее, но всё равно десятки секунд для холодного pull нетривиального образа. Сравните с composite (миллисекунды) или JavaScript-экшеном (субсекундный старт node): Docker-экшен добавляет плоский попрогонный налог, невидимый в долгой джобе и жестокий в быстрой, триггерящейся сотни раз в день.

Прежде чем добавить Docker-экшен в быстрый воркфлоу, срабатывающий сотни раз в день, спроси себя: требует ли логика произвольного окружения контейнера — или JavaScript-экшен справится? Если ответ «да, нужен Docker» — следующий вопрос: как срезать стартовый налог. Митигация — опубликовать пресобранный образ в реестр (GHCR) и сослаться на него через docker://, превращая попрогонную сборку в попрогонный pull и давая кэшированию слоёв помочь. Но это добавляет релизный пайплайн для самого образа. Две заметки о безопасности наследуются из мира контейнеров и значат здесь больше, чем для других типов: пиньте базовый образ по digest (FROM alpine:3.20@sha256:...), чтобы сборка была воспроизводимой и пере-тегированная апстрим-база не могла молча изменить ваш экшен; и пиньте любые экшены, что ваш воркфлоу использует для вызова этого, по commit SHA — та же supply-chain-гигиена, что у других типов. Правило решения резкое: выбирайте Docker, только когда вам по-настоящему нужно окружение, что composite и JavaScript дать не могут, и примите только-Linux плюс стартовый налог как цену этого контроля.