bot-backend
c930b12d5f
All checks were successful
CI Trade-In / changes (pull_request) Successful in 7s
CI Trade-In / backend-tests (pull_request) Has been skipped
CI / changes (pull_request) Successful in 9s
CI Trade-In / browser-tests (pull_request) Has been skipped
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / frontend-tests (pull_request) Successful in 1m13s
CI / openapi-codegen-check (pull_request) Successful in 2m5s
CI / backend-tests (pull_request) Successful in 17m19s
20.08 деплой ПТИЦЫ (run 8083) упал за 5 секунд:
unable to lease content: lease does not exist: not found
Все 7 образов ушли в Interrupted через 0.8с после старта пула. Причина — не
в ПТИЦЕ: через 0.4с после обрыва соседний деплой Trade-In напечатал
«Deleted Images:» своего `docker image prune -af`.
Оба деплоя ходят по SSH в ОДИН докер-демон: стеки gendesign-* и tradein-*
плюс сам forgejo-runner живут на одной VM (проверено `docker ps` на хосте).
Группы были разные — deploy-prod и deploy-tradein-prod — поэтому Forgejo
запускал их параллельно. `cancel-in-progress: false` не спасал: он про раны
ВНУТРИ группы, а гонка была МЕЖДУ группами.
Последствие было тихим: голова main показывала success, но зелёным был
Trade-In'овый деплой этой головы, а деплой ПТИЦЫ висел на своём, более раннем
коммите с исходом failure. Прод остался на старом коде — #2946 и #2947 не
доехали и были выкачены отдельным workflow_dispatch.
Почему общая группа, а не flock на хосте. Host-lock сериализовал бы только
докер-секцию, не заставляя деплои ждать чужих билдов (~6 мин). Но у него своя
отказная мода: дочерний процесс наследует fd лока, и при аварийной смерти
job'а лок залипает. Проверено на самой VM: после kill -9 держателя следующий
претендент лок НЕ получил. Залипший лок блокирует прод-деплои на весь таймаут.
Планировщик Forgejo сериализует без лок-файла, залипать там нечему —
платим ожиданием, покупаем отсутствие целого класса отказов.
Гейт backend/tests/ops/test_2950_deploy_concurrency_group.py фиксирует
инвариант. Мутационно проверен: разводка групп обратно, cancel-in-progress:
true и удаление секции concurrency краснят его (1, 1 и 3 упавших теста),
контроль зелёный.
В фильтр changes добавлены сами deploy-workflow'ы — иначе правка, разводящая
группы, не трогает 'backend/**', backend-tests пропускается, и гейт не
исполняется ровно на той правке, от которой стережёт. Тот же класс, что #2587.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| alembic | ||
| app | ||
| db/init | ||
| output | ||
| scripts | ||
| tests | ||
| .dockerignore | ||
| .env.example | ||
| .env.runtime.example | ||
| .gitignore | ||
| alembic.ini | ||
| debug.log | ||
| Dockerfile | ||
| pyproject.toml | ||
| uv.lock | ||