← Обзор трека · Выкатка · Откат
История GitHub Deployments
План, ещё не внедрено
Здесь описана целевая запись релиза из backend#42. Текущий workflow уже использует environment production, но ещё не записывает digest образа в собственный Deployment.
Что хранит запись
GitHub Deployment — запись о попытке развернуть конкретную версию в production. Статусы и ссылка на логи показывают, чем попытка закончилась.
| Поле | Что узнаёт читатель |
|---|---|
ref | SHA образа: коммит, из которого собран выбранный образ |
payload.image_ref и digest | Полная ссылка ghcr.io/cringe-driven-development-team/backend@sha256:… и digest выбранного образа |
Действие в payload | deploy или rollback |
Run в payload | Ссылка на запуск текущей выкатки или отката; при откате отличается от CI, который собрал образ |
| Последний статус | Подтверждён ли результат на production |
При ручном откате сам workflow запускается на main, но выбранный прежний образ относится к другому SHA. Поэтому github.sha этого запуска нельзя выдавать за версию API: в новом Deployment ref указывает на целевой SHA. Если для одного SHA существуют разные успешные digest, одного SHA для выбора образа недостаточно; workflow отклоняет неоднозначную цель до VPS.
Когда появляется success
CD создаёт Deployment для выбранного SHA до переключения API и добавляет статусы по мере выполнения. success ставится после подтверждения образа запущенного контейнера, его healthy и ответа публичного API через HTTPS. Успех команды Ansible сам по себе ещё не доказывает работу production. Если контейнер упал позже, прежний success остаётся историей проверки в момент выкатки. Для выбора цели отката этого достаточно; текущую работающую версию он не доказывает.
Если проверка не прошла, запись и карточка указывают этап сбоя и только подтверждённое состояние; неизвестную версию называют «неизвестно». Ошибка отправки Telegram-сообщения видна в workflow, но не превращает проверенный деплой в неуспешный.
Почему нет двух записей на одну попытку
Сегодня GitHub автоматически создаёт Deployment для job с environment production: это следует из механизма environments и текущего cd.yml. Автоматическая запись привязана к ref запуска и не содержит выбранный digest.
В целевом потоке CD создаёт запись явно через GitHub Deployments API. Для environment job задаётся deployment: false: она сохраняет доступ к секретам и правилам production, а GitHub не создаёт дублирующую запись. Этот режим описан в документации environments.
После чтения истории релизов можно перейти к выбору версии для отката или к исполнению через Ansible.