ops: смоук периметра МЕРЫ не запускается после деплоя — регресс живёт до суток #2917

New issue

Closed

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

lekss361 commented

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

Owner

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

Что не так

scripts/smoke-mera-perimeter.sh — единственная проверка, которая видит публичный периметр целиком (короткие адреса, 301 с длинных, публичный API, закрытость B2B-путей на этом домене). Запускается он только по workflow_dispatch и по cron 17 6 * * * (.forgejo/workflows/perimeter-smoke.yml).

Ни deploy.yml, ни deploy-tradein.yml его не дёргают. То есть после выкатки регресс периметра живёт до суток, и узнает о нём либо ночной cron, либо владелец — ровно тот сценарий, против которого тесты в #2913 и написаны.

Для PR, чья главная логика живёт в конфиге прокси, это единственный настоящий гейт, и он асинхронный.

Что сделать

Дёргать смоук после успешного деплоя (обоих пайплайнов — конфиг прокси и фронт едут раздельно). Красный смоук — уведомление, а не молчание.

Смежное: смоук не гейтится ничем сам по себе

scripts/smoke-mera-perimeter.sh не входит ни в один paths-фильтр и не линтуется (shellcheck в репозитории нет). Опечатка в нём обнаружится только следующим утром — и будет выглядеть как регресс периметра. Стоит добавить его в фильтры и прогонять bash -n хотя бы синтаксически.

Смежное: одна проверка ходит во внешний геокодер

check_post .../public/mera/suggest '{"q":"Малышева"}' 200 — «Малышева» это Екатеринбург, запрос обслуживает локальный кадастровый тир без внешних вызовов. Но если тир промахнётся, запрос уйдёт в DaData: тогда падение/квота/таймаут провайдера дадут красный «регресс периметра» без всякого регресса. Стоит либо смягчить ожидание, либо проверять ручку запросом, который заведомо не выходит наружу.

Проверить

sed -n 15,40p .forgejo/workflows/perimeter-smoke.yml
grep -rn "smoke-mera-perimeter\|shellcheck" .forgejo/

Связано: #2913.

Найдено критиком полноты при ревью PR #2913. ## Что не так `scripts/smoke-mera-perimeter.sh` — единственная проверка, которая видит публичный периметр целиком (короткие адреса, 301 с длинных, публичный API, закрытость B2B-путей на этом домене). Запускается он только по `workflow_dispatch` и по cron `17 6 * * *` (`.forgejo/workflows/perimeter-smoke.yml`). Ни `deploy.yml`, ни `deploy-tradein.yml` его не дёргают. То есть после выкатки регресс периметра живёт до суток, и узнает о нём либо ночной cron, либо владелец — ровно тот сценарий, против которого тесты в #2913 и написаны. Для PR, чья главная логика живёт в конфиге прокси, это единственный настоящий гейт, и он асинхронный. ## Что сделать Дёргать смоук после успешного деплоя (обоих пайплайнов — конфиг прокси и фронт едут раздельно). Красный смоук — уведомление, а не молчание. ## Смежное: смоук не гейтится ничем сам по себе `scripts/smoke-mera-perimeter.sh` не входит ни в один `paths`-фильтр и не линтуется (shellcheck в репозитории нет). Опечатка в нём обнаружится только следующим утром — и будет выглядеть как регресс периметра. Стоит добавить его в фильтры и прогонять `bash -n` хотя бы синтаксически. ## Смежное: одна проверка ходит во внешний геокодер `check_post .../public/mera/suggest '{"q":"Малышева"}' 200` — «Малышева» это Екатеринбург, запрос обслуживает локальный кадастровый тир без внешних вызовов. Но если тир промахнётся, запрос уйдёт в DaData: тогда падение/квота/таймаут провайдера дадут красный «регресс периметра» без всякого регресса. Стоит либо смягчить ожидание, либо проверять ручку запросом, который заведомо не выходит наружу. ## Проверить ``` sed -n 15,40p .forgejo/workflows/perimeter-smoke.yml grep -rn "smoke-mera-perimeter\|shellcheck" .forgejo/ ``` Связано: #2913.