ci: правка конфига прокси больше не тянет полный деплой Site Finder (#2916) #2925

Merged

bot-backend merged 1 commit from ci/2916-caddy-only-deploy into main

2026-08-19 08:39:02 +00:00

bot-backend commented

2026-08-19 08:37:22 +00:00

Collaborator

Что было

Caddyfile попадает в фильтр infra, поэтому правка одной строки allowlist'а ради
meraocenka.ru запускала:

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

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

Быстрый путь

Новый job deploy-caddy: синхронизирует репозиторий на VM и делает caddy reload.
Без пересборки, без миграций, без пересоздания контейнеров.

Включается только когда правка не трогает ничего кроме конфига — пара фильтров
caddy + non_caddy (всё остальное), путь идёт при caddy && !non_caddy. Одного
caddy мало: он true и когда вместе с конфигом приехал бэкенд, а там нужен полный
деплой.

caddy reload, а не up -d --force-recreate caddy. Полный деплой пересоздаёт
контейнер осознанно — reload отказался бы принять битый конфиг и оставил бы работать
старый, что на общем деплое скрыло бы поломку. Здесь ровно наоборот: правится только
конфиг, и отказ применить битый — это то, что нужно. Ненулевой код → job красный, домены
продолжают обслуживаться старым конфигом. --force-recreate на опечатке увёл бы
контейнер в crash-loop и уронил бы все домены сразу.

Безопасные умолчания

github.event_name == 'push' первым множителем в caddy_only: на
workflow_dispatch у paths-filter нет диффа, и никакой его ответ не должен уметь
отключить сборку — ручной прогон обязан оставаться полным.
Если выражение caddy_only вдруг вычислится не в 'true' (act ведёт себя иначе, чем
GitHub), поведение вырождается в сегодняшнее: полный деплой, быстрый путь не
запускается. Ошибка в эту сторону ничего не ломает.
deploy-status теперь принимает любой из двух путей. Требовать deploy == success
как раньше значило бы красить каждую правку прокси, которая как раз прошла.
Смоук периметра (#2917) слушает оба пути — на быстром он нужнее всего, там меняется
ровно то, что смоук проверяет.

Проверено

caddy reload прогнан на проде с текущим конфигом — механизм рабочий, а не
предполагаемый:

{"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
{"msg":"adapted config to JSON","adapter":"caddyfile"}
rc=0

Смоук периметра сразу после этой перезагрузки — 27 из 27 зелёные.

Семантика фильтров проверена на реальных коммитах, а не на теории. Из последних 400:

трогали конфиг прокси            12
из них ТОЛЬКО конфиг              3   ← пошли бы быстрым путём
   208173d8  fix(mera/b2c): длинные адреса реально редиректят
   2b24408c  docs(tradein/caddy): обоснование scrub
   01bf4a91  feat(tradein/caddy): снять basic_auth с /trade-in

Механизм не мёртвый (сработал бы на четверти правок прокси, включая правку периметра
МЕРЫ) и не срабатывает лишний раз: f30820bb (Caddyfile + docker-compose.prod.yml)
даёт caddy_only=false — компоуз требует полного деплоя и получает его.

yaml.safe_load — валиден, состав и зависимости job'ов проверены разбором
caddy reload на проде — rc=0
смоук периметра после reload — 27/27

Что этот PR не делает

Не выносит блок meraocenka.ru в отдельный файл (второй вариант из задачи). Быстрый путь
решает главное — радиус поражения — и не трогает структуру конфига; разделение файлов
можно сделать позже, оно от этого не зависит.

Closes #2916

## Что было `Caddyfile` попадает в фильтр `infra`, поэтому правка одной строки allowlist'а ради `meraocenka.ru` запускала: - пересборку трёх образов Site Finder; - `git reset --hard` на боевой VM; - применение **всех** pending `data/sql/*.sql` в боевой БД `gendsgn`; - `--force-recreate` бэкенда, воркера, beat и caddy. То есть радиус поражения правки, относящейся к чужому домену, — `gendsgn.ru` целиком, включая миграции продукта, который в этот момент никто катить не собирался. ## Быстрый путь Новый job `deploy-caddy`: синхронизирует репозиторий на VM и делает `caddy reload`. Без пересборки, без миграций, без пересоздания контейнеров. Включается **только** когда правка не трогает ничего кроме конфига — пара фильтров `caddy` + `non_caddy` (всё остальное), путь идёт при `caddy && !non_caddy`. Одного `caddy` мало: он `true` и когда вместе с конфигом приехал бэкенд, а там нужен полный деплой. **`caddy reload`, а не `up -d --force-recreate caddy`.** Полный деплой пересоздаёт контейнер осознанно — `reload` отказался бы принять битый конфиг и оставил бы работать старый, что на общем деплое скрыло бы поломку. Здесь ровно наоборот: правится только конфиг, и отказ применить битый — это то, что нужно. Ненулевой код → job красный, домены продолжают обслуживаться старым конфигом. `--force-recreate` на опечатке увёл бы контейнер в crash-loop и уронил бы **все** домены сразу. ## Безопасные умолчания - `github.event_name == 'push'` **первым множителем** в `caddy_only`: на `workflow_dispatch` у paths-filter нет диффа, и никакой его ответ не должен уметь отключить сборку — ручной прогон обязан оставаться полным. - Если выражение `caddy_only` вдруг вычислится не в `'true'` (act ведёт себя иначе, чем GitHub), поведение **вырождается в сегодняшнее**: полный деплой, быстрый путь не запускается. Ошибка в эту сторону ничего не ломает. - `deploy-status` теперь принимает **любой** из двух путей. Требовать `deploy == success` как раньше значило бы красить каждую правку прокси, которая как раз прошла. - Смоук периметра (#2917) слушает оба пути — на быстром он нужнее всего, там меняется ровно то, что смоук проверяет. ## Проверено **`caddy reload` прогнан на проде** с текущим конфигом — механизм рабочий, а не предполагаемый: ``` {"msg":"using config from file","file":"/etc/caddy/Caddyfile"} {"msg":"adapted config to JSON","adapter":"caddyfile"} rc=0 ``` Смоук периметра сразу после этой перезагрузки — **27 из 27 зелёные**. **Семантика фильтров проверена на реальных коммитах**, а не на теории. Из последних 400: ``` трогали конфиг прокси 12 из них ТОЛЬКО конфиг 3 ← пошли бы быстрым путём 208173d8 fix(mera/b2c): длинные адреса реально редиректят 2b24408c docs(tradein/caddy): обоснование scrub 01bf4a91 feat(tradein/caddy): снять basic_auth с /trade-in ``` Механизм не мёртвый (сработал бы на четверти правок прокси, включая правку периметра МЕРЫ) и не срабатывает лишний раз: `f30820bb` (Caddyfile **+** docker-compose.prod.yml) даёт `caddy_only=false` — компоуз требует полного деплоя и получает его. - [x] `yaml.safe_load` — валиден, состав и зависимости job'ов проверены разбором - [x] `caddy reload` на проде — rc=0 - [x] смоук периметра после reload — 27/27 ## Что этот PR не делает Не выносит блок `meraocenka.ru` в отдельный файл (второй вариант из задачи). Быстрый путь решает главное — радиус поражения — и не трогает структуру конфига; разделение файлов можно сделать позже, оно от этого не зависит. Closes #2916

bot-backend added 1 commit 2026-08-19 08:37:22 +00:00

ci: правка конфига прокси больше не тянет полный деплой Site Finder

CI Trade-In / changes (pull_request) Successful in 7s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Has been skipped

Details

CI / changes (pull_request) Successful in 9s

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

1fa289e305

Caddyfile лежит в фильтре `infra`, поэтому правка одной строки allowlist'а
ради meraocenka.ru запускала: пересборку трёх образов Site Finder,
`git reset --hard` на боевой VM, применение ВСЕХ pending data/sql/*.sql в
боевой БД gendsgn и `--force-recreate` бэкенда, воркера, beat и caddy.
Радиус поражения правки, относящейся к чужому домену, — gendsgn.ru целиком,
включая миграции продукта, который никто в этот момент катить не собирался.

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

БЫСТРЫЙ ПУТЬ

Новый job deploy-caddy: синхронизирует репозиторий на VM и делает
`caddy reload`. Без пересборки, без миграций, без пересоздания контейнеров.

Включается ТОЛЬКО когда правка не трогает больше ничего: пара фильтров
`caddy` + `non_caddy` (всё остальное), быстрый путь идёт при caddy && !non_caddy.
Одного `caddy` мало — он true и когда вместе с конфигом приехал бэкенд.

`caddy reload`, а НЕ `up -d --force-recreate caddy`. Полный деплой
пересоздаёт контейнер осознанно (reload отказался бы принять битый конфиг и
скрыл бы поломку). Здесь наоборот: правится только конфиг, и отказ применить
битый — ровно то, что нужно. Ненулевой код → job красный, домены продолжают
работать на старом конфиге. `--force-recreate` на опечатке увёл бы контейнер
в crash-loop и уронил ВСЕ домены сразу.

БЕЗОПАСНЫЕ УМОЛЧАНИЯ

`github.event_name == 'push'` первым множителем в caddy_only: на
workflow_dispatch у paths-filter нет диффа, и никакой его ответ не должен
уметь отключить сборку — ручной прогон обязан оставаться полным.

Если выражение caddy_only вдруг вычислится не в 'true' (иначе ведёт себя
act), поведение вырождается в СЕГОДНЯШНЕЕ: полный деплой, быстрый путь не
запускается. Ошибка в эту сторону ничего не ломает.

deploy-status теперь принимает ЛЮБОЙ из двух путей: требовать
`deploy == success` как раньше значило бы красить каждую правку прокси,
которая как раз прошла. Смоук периметра (#2917) тоже слушает оба — на
быстром пути он нужнее всего, там меняется ровно то, что смоук проверяет.

ПРОВЕРЕНО

- `caddy reload` прогнан на проде с текущим конфигом: rc=0, конфиг принят;
  смоук периметра после этого 27 из 27 зелёные.
- Семантика фильтров проверена на реальных коммитах: из последних 400
  конфиг прокси трогали 12, только конфиг — 3 (в т.ч. 208173d8, правка
  периметра МЕРЫ). То есть механизм не мёртвый и не срабатывает лишний раз.
- f30820bb (Caddyfile + docker-compose) даёт caddy_only=false — компоуз
  требует полного деплоя, и он его получает.

Closes #2916