container: для job
Тема дорожной карты · GitHub Actions
Ключ container: в определении job GitHub Actions запускает все шаги steps: внутри указанного Docker-контейнера, а не непосредственно на ВМ runner, обеспечивая герметичную и воспроизводимую среду выполнения для всего job CI/CD-пайплайна. Когда задаётся container: — например, container: node:20-alpine — GitHub Actions загружает образ на runner, запускает контейнер с примонтированным томом рабочего пространства и выполняет каждый последующий шаг run: внутри этого контейнера, гарантируя фиксированные версии зависимостей независимо от установленного на хосте runner. Блок container: поддерживает image:, credentials: для аутентификации в приватных реестрах, env: для переменных окружения уровня контейнера, ports: для открытия внутренних сервисов и volumes: для монтирования дополнительных путей, давая авторам пайплайна точный контроль над контекстом выполнения job. Job-контейнеры особенно ценны для пайплайнов непрерывной интеграции, требующих конкретного дистрибутива Linux, фиксированной версии компилятора или кастомных системных библиотек, отличных от предустановленных в GitHub-hosted runners. Job-контейнеры дополняют сайдкар-контейнеры services: и вместе позволяют одному job GitHub Actions реплицировать многоконтейнерную production-топологию для тщательного интеграционного тестирования в рамках одного запуска workflow.
Как это работает
container: для job: docker/build-push-action, docker/login-action, docker/setup-buildx-action — каноническое трио для build + push образа. Multi-arch через buildx + qemu (docker/setup-qemu-action). Build-кеш через cache-from: type=gha + cache-to: type=gha (использует GHA-cache backend — встроенная поддержка). Container-actions (ваш action работает внутри Docker-образа) и service containers (services: блок для sidecar БД, Redis при тестах).
Когда применять
buildx — для любого нетривиального Docker-образа: multi-arch + layer cache + cross-platform. Push в GHCR (ghcr.io) — бесплатный приватный storage, привязанный к репо. services: — для integration-тестов с Postgres/Redis/Kafka: стартуют до шагов. Multi-stage Dockerfile + buildx cache + GHA-cache backend даёт < 2 мин пересборки на cache hit.
Типичные ошибки
Ловушки container: для job: push образов на каждый PR (засорённый registry — push только с main); базовые Docker-образы не запиннены по digest (сегодняшний node:22-alpine ≠ завтрашний); docker login напрямую с PAT вместо docker/login-action (теряет ergonomic-улучшения); долгие multi-arch сборки без buildx-кеша (10× медленнее).