GitHub Actions: настройка и выпуск

Эта инструкция использует окружение production и ветку main. Сервер и профиль окружения подготовьте по общей инструкции CI/CD.

1. Создайте workflow

В Deployment включите Docker и Production deployment. Выберите CI provider — GitHub. В Deployment environments создайте профиль production, заполните серверы и домены, выберите доставку Archive или Registry. Сохраните настройки, выполните Generate и добавьте сгенерированный профиль и custom-файл без секретов в Git.

Генератор создаст .github/workflows/admingen.yml. Отправьте проект в GitHub, включите Actions и защитите ветку main. Workflow использует runner ubuntu-24.04 и Docker Buildx. Свои задания размещайте в отдельных workflow-файлах: admingen.yml обновляется при Generate.

2. Настройте сборку

По умолчанию build берёт профиль production из Git. Чтобы собирать другой профиль, создайте repository variable ADMINGEN_BUILD_ENVIRONMENT в Settings → Secrets and variables → Actions → Variables и укажите его имя. Сгенерированный профиль и custom-файл должны быть закоммичены.

Полный JSON в secrets не требуется. Если сознательно храните конфиг вне Git, ADMINGEN_BUILD_ENVIRONMENT_JSON в repository secrets полностью переопределяет профиль сборки, а ADMINGEN_ENVIRONMENT_JSON в environment secrets — профиль операции. В них вставляется полное содержимое ручного JSON, а не путь к файлу. Не создавайте эти переопределения для обычного UI-профиля.

Secrets registry добавляются в Settings → Secrets and variables → Actions → Repository secrets.

Для Registry при необходимости добавьте:

Для GHCR шаблон может использовать GITHUB_TOKEN, если этому репозиторию разрешён доступ к пакетам. Для другого registry задайте обе переменные. Archive не требует registry credentials; для скачивания базовых образов и зависимостей сборке всё равно нужна сеть.

3. Создайте environment для выпуска

В Settings → Environments создайте production, разрешите deployment из main. Настройте required reviewers, если эта возможность доступна и вам нужно подтверждение выпуска.

Добавьте environment secrets:

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

Для Registry при необходимости добавьте ADMINGEN_REGISTRY_USER и ADMINGEN_REGISTRY_PASSWORD с правами чтения. Для GHCR доступный workflow token может заменить эту пару; для других registry задайте свои значения. Это доступ runner, а сервер использует постоянный токен из provisioning.

JSON сборки и выпуска должны описывать одно окружение и одинаковую доставку. При Archive registry secrets не нужны.

4. Получите сборку

Отправьте код в main и откройте Actions → Admingen. Дождитесь успешного build.

Артефакт admingen-release содержит release.json, а при Archive — ещё и соответствующий *.images.tar. Храните их рядом. Артефакт доступен 90 дней.

Для первой установки скачайте его и выполните provision по инструкции Archive или Registry, используя скачанный релиз вместо повторного build. Workflow не выполняет первоначальный provision.

5. Выпустите выбранную сборку

1. Откройте успешный workflow run от push в main.
2. Скопируйте его числовой ID из адреса: в .../actions/runs/123456789 нужен 123456789.
3. Откройте Actions → Admingen → Run workflow.
4. Выберите ветку main, operation: deploy, environment: production.
5. В build_run_id вставьте ID из шага 2.
6. Запустите workflow, подтвердите deployment, если требуется, и дождитесь завершения.
7. Откройте приложение.

Workflow проверит, что выбранная сборка успешна, относится к этому workflow и push в main. Затем скачает артефакт и выпустит именно его. В build_run_id не подходят commit SHA или номер pull request. Если артефакт удалён, эту сборку выпустить через workflow не получится.

6. Настройте обслуживание

Создайте environment production-maintenance, разрешите main и добавьте туда те же environment secrets. Ручное подтверждение ежедневного запуска отключите. Обслуживание использует тот же профиль production.

В workflow уже есть расписание: ежедневно в 02:17 UTC. Оно создаёт резервную копию и обслуживает сертификаты. При backup.kind: none копия пропускается. Новые релизы расписание не выпускает.

Для ручного обслуживания выберите в Run workflow operation: backup или certificates, environment: production, ветку main. build_run_id не нужен. Явный backup при None завершится ошибкой.

Если окружение называется staging, для ручных операций создайте environments staging и staging-maintenance с их secrets. Имя build-профиля задаёт ADMINGEN_BUILD_ENVIRONMENT; ежедневное расписание по-прежнему обслуживает production. Для другого расписания создайте отдельный workflow.

Если workflow не работает