vercel/vcr-action/login позволяет пушить образы в Vercel Container Registry из GitHub Actions

Коротко: что делает Action и какую проблему решает

vercel/vcr-action/login позволяет workflow на GitHub аутентифицироваться в Vercel Container Registry (VCR) через GitHub OIDC и получить краткоживущий Vercel access token. Action обменивает id‑token workflow на временный токен Vercel, использует его для входа на vcr.vercel.com и автоматически аннулирует токен по завершении задания. Главная выгода — возможность пушить образы в VCR без хранения долгоживущих регистрационных учётных данных в переменных окружения или секретах репозитория.

Как настроить в GitHub Actions: шаги, переменные и разрешения

Настройка делится на три части: политика OIDC в Vercel, хранение идентификаторов в переменных репозитория и сам шаг логина в workflow. На стороне Vercel нужно создать OIDC‑политику для команды, которая соответствует репозиторию и конкретному workflow, и дать этой политике права чтения‑записи к VCR.

В репозитории GitHub сохраняют идентификаторы команды и проекта как переменные (в примере — VERCEL_TEAM_ID, VERCEL_TEAM_SLUG, VERCEL_PROJECT_SLUG и VCR_REPOSITORY). В workflow требуется явно дать разрешение id-token: write, чтобы GitHub выдавал OIDC‑токен для обмена.

В самом workflow шаг логина добавляют перед сборкой и пушем образа. Вызов vercel/vcr-action/login@v1 принимает параметр team со значением переменной VERCEL_TEAM_ID. После успешного логина можно вызывать стандартные действия для сборки и пуша (например, docker/build-push-action), указывая в теге реестр vcr.vercel.com/{team_slug}/{project_slug}/{repository}:tag. По завершении job Action выходит и отзывает Vercel‑токен.

Практический контекст: где и как это использовать

Если вы храните и разворачиваете кастомные контейнеры в экосистеме Vercel, интеграция пуша образов прямо из CI упрощает автоматизацию релизов и Sandbox‑образов. Workflow с vercel/vcr-action/login пригодится для автоматического билда образов при пуше в main или создании тегов: инженер комммитит изменения, CI собирает образ и пушит его в VCR без ручного вращения учётных данных.

Action по умолчанию аутентифицирует Docker, поэтому для стандартных пайплайнов в большинстве проектов изменений не требуется. Если в процессе сборки вы используете альтернативные runtime‑движки, у Action есть опция engines: можно переключиться на Podman или Buildah. В большинстве сценариев логин через OIDC избавляет от необходимости обновлять и хранить долгие токены в секретах и упрощает ротацию доступа.

После того как VCR подготовит linux/amd64‑образ, его можно использовать как кастомный Sandbox‑образ в том же проекте Vercel, ссылаясь на него через формат имени образа в реестре. Это удобно для тестовых сред и для запуска компонентов в окружении, близком к продакшену.

Ограничения и что проверить перед внедрением

Потребуется создать и правильно настроить OIDC‑политику в вашей Vercel‑команде: без соответствия политики и workflow обмен OIDC на Vercel‑токен не сработает. Убедитесь, что политика даёт read‑write доступ к VCR для нужных репозиториев и workflow.

Нужно хранить в GitHub значения идентификаторов команды и проекта — они используются для формирования тега образа. Если переменные заданы неверно, образ попадёт в другой путь или пуш завершится с ошибкой. Обратите внимание, что в примере целевая платформа — linux/amd64; если вам нужны другие архитектуры или мультиархитектурные артефакты, проверьте совместимость сборщика и поведение VCR при подготовке таких образов.

Action аутентифицирует Docker по умолчанию; если ваша сборка полагается на Podman или Buildah, задайте соответствующие engines. Наконец, автоматическое отзов токена происходит при завершении задания, поэтому длительные фоновые операции, предполагающие непрерывный доступ к реестру после завершения job, будут прерваны.