ops: правка Caddyfile ради МЕРЫ пересобирает и передеплоивает Site Finder, применяя все pending SQL #2916

New issue

Closed

opened 2026-08-16 07:02:23 +00:00 by lekss361 · 0 comments

lekss361 commented

2026-08-16 07:02:23 +00:00

Owner

Найдено критиком полноты при ревью PR #2913.

Что происходит

Caddyfile лежит в корне репозитория и попадает в фильтр infra (.forgejo/workflows/deploy.yml:67). Джобы build-backend и deploy идут при infra == 'true', поэтому правка одной строки прокси ради публичного домена МЕРЫ запускает:

пересборку образов Site Finder;
git reset --hard на боевой VM;
применение всех pending data/sql/*.sql в боевой БД gendsgn;
--force-recreate backend worker beat caddy.

То есть blast radius правки, относящейся к meraocenka.ru, — это gendsgn.ru целиком, включая миграции чужого продукта, которые в этот момент никто не собирался катить.

Почему это опасно именно сейчас

Публичный периметр МЕРЫ живёт в Caddyfile и будет меняться часто: новая страница = новая строка allowlist. Каждая такая правка тянет за собой полный деплой Site Finder.

Обратная сторона той же связи: если deploy.yml упадёт на миграции, конфиг прокси не доедет — а фронт МЕРЫ едет отдельным пайплайном (deploy-tradein.yml) и приедет. Кнопки лэндинга будут вести на короткие адреса, которых в allowlist ещё нет.

Что стоит рассмотреть

Разделить фильтр: правка только Caddyfile → отдельный job, который синхронизирует конфиг и делает caddy reload, без пересборки образов и без миграций.
Либо вынести конфиг публичного домена в отдельный файл (caddy/mera.caddy) с собственным фильтром, оставив общий Caddyfile для инфраструктурных правок.

Проверить

grep -n "paths:" -A12 .forgejo/workflows/deploy.yml
sed -n 530,570p .forgejo/workflows/deploy.yml

Связано: #2913 (там добавлен caddy validate как pre-merge гейт — но он не решает вопрос blast radius).

Найдено критиком полноты при ревью PR #2913. ## Что происходит `Caddyfile` лежит в корне репозитория и попадает в фильтр `infra` (`.forgejo/workflows/deploy.yml:67`). Джобы `build-backend` и `deploy` идут при `infra == 'true'`, поэтому правка одной строки прокси ради публичного домена МЕРЫ запускает: - пересборку образов Site Finder; - `git reset --hard` на боевой VM; - применение **всех** pending `data/sql/*.sql` в боевой БД `gendsgn`; - `--force-recreate backend worker beat caddy`. То есть blast radius правки, относящейся к `meraocenka.ru`, — это `gendsgn.ru` целиком, включая миграции чужого продукта, которые в этот момент никто не собирался катить. ## Почему это опасно именно сейчас Публичный периметр МЕРЫ живёт в `Caddyfile` и будет меняться часто: новая страница = новая строка allowlist. Каждая такая правка тянет за собой полный деплой Site Finder. Обратная сторона той же связи: если `deploy.yml` упадёт на миграции, конфиг прокси не доедет — а фронт МЕРЫ едет отдельным пайплайном (`deploy-tradein.yml`) и приедет. Кнопки лэндинга будут вести на короткие адреса, которых в allowlist ещё нет. ## Что стоит рассмотреть - Разделить фильтр: правка только `Caddyfile` → отдельный job, который синхронизирует конфиг и делает `caddy reload`, без пересборки образов и без миграций. - Либо вынести конфиг публичного домена в отдельный файл (`caddy/mera.caddy`) с собственным фильтром, оставив общий `Caddyfile` для инфраструктурных правок. ## Проверить ``` grep -n "paths:" -A12 .forgejo/workflows/deploy.yml sed -n 530,570p .forgejo/workflows/deploy.yml ``` Связано: #2913 (там добавлен `caddy validate` как pre-merge гейт — но он не решает вопрос blast radius).