SourceCraft CI и развёртывание на VPS

Оглавление · Основы CI/CD · Релизный контракт

Репозиторий — zakharov-dev/gheilt. Оба remote, origin и sourcecraft, указывают на него. GitHub Actions отключены, workflow удалены; GitHub не участвует в доставке. Registry — существующий YC crpml6ifd12s8cbmbg3m. Образы собираются только в SourceCraft CI для linux/amd64. На VPS устанавливаются готовые образы по digest, без сборки npm/pnpm или Docker.

Окружения

Источник	Назначение	Публикация
Собственный PR	Полный изолированный стенд	`web.pr-N.gheilt.mxsource.xyz` и соседние CMS/media/Storybook/docs
`main`	test	`web.test.gheilt.mxsource.xyz` и соседние сервисы
`release/X.Y`	staging	`web.staging.gheilt.mxsource.xyz` и соседние сервисы
Последний опубликованный stable `vX.Y.Z`	production	`gheilt.mxsource.xyz`, `cms.`, `media.`, `storybook.`, `docs.`

CI сайта проверяется с изолированной CMS-фикстурой. Полные стенды получают копию опубликованного контента текущей production CMS и Garage; внешний сайт не используется. Production получает те же четыре digest, что staging, без повторной сборки. Draft и prerelease остаются вне production. Подробнее: релизные ветки и жизненный цикл стендов.

Как доставка доходит до VPS

Конфигурация — .sourcecraft/ci.yaml. Проверки отделены от публикации с IAM. Service connection yandex-cloud выдаёт CI временный доступ к registry. Capsule связывает точный SHA, запуск и digest каждого образа. Control plane из доверенного main публикует состояние веток, PR и native Releases.

VPS сам читает registry по HTTPS: sourcecraft-receive.timer запускает receiver каждые две минуты, control plane обновляется раз в десять минут. Входящий SSH от CI не нужен. Puller key хранится только на VPS; PAT разработчика не передаётся контейнерам. Trusted scripts установлены в /opt/gheilt/preview-tools/SHA, а не исполняются из произвольного PR checkout.

Receiver использует общий /opt/gheilt/deploy.lock. Для production сначала проверяются совместимость CMS и восстановление private backup. Caddy переключает четыре приложения; PostgreSQL, Garage и uploads остаются общими. Active receipt записывается после публичного smoke, затем прежние приложения останавливаются, а совпавшая staging generation охлаждается. Production всегда работает.

Обычный выпуск

Из своей ветки создайте PR в main или точную release-ветку. Для release branch, changelog и draft используйте maintainer CLI. После готовности staging публикация native stable Release запускает promotion. Теги не перемещайте.

Для чтения запусков:

src run list -R zakharov-dev/gheilt --json
src run get NUMBER -R zakharov-dev/gheilt --json

На VPS состояние доставки читается без сборок:

systemctl status sourcecraft-receive.service sourcecraft-receive.timer
journalctl -u sourcecraft-receive.service --no-pager -n 50

Успех CI подтверждает сборку и публикацию. Работающий production подтверждают active receipt, фактические digest контейнеров и публичный X-App-Release. При ошибке сначала выясните фазу intent и состояние данных; не запускайте повторный bootstrap и не удаляйте тома ради восстановления приложения.

Подготовка хоста и административный доступ

Используются Docker Compose, Python 3, systemd, curl, flock и Linux-утилиты. Пользователь — atmanki-deploy, каталог — /opt/gheilt, backend network — atmanki_default. Dedicated SSH key нужен для администрирования; host key проверяется через StrictHostKeyChecking=yes. Членство в docker group даёт широкие полномочия на хосте и не является restricted shell.

Bootstrap нового хоста — scripts/deploy/bootstrap.sh; существующий хост не переинициализируют при обновлении. Старые имена томов и роли PostgreSQL сохраняются: смена Compose project не переносит данные. История переноса — отчёт Atmanki. Caddy собирается отдельно workflow caddy-image при изменении proxy; обычный application commit его не пересобирает.