Поправка к #2952. Там я свёл обе группы concurrency к одной и написал, что это
сериализует деплои. Проверил сразу после мержа — не сериализует.
Коммит 2a01dea1 трогает оба деплой-workflow, поэтому запустил обе цепочки. При
работающей общей группе вторая не стартовала бы вовсе. На раннере в этот момент:
TASK-21431_WORKFLOW-Deploy-Trade-In_JOB-build-frontend
TASK-21430_WORKFLOW-Deploy-Trade-In_JOB-test
TASK-21428_WORKFLOW-Deploy_JOB-build-frontend
TASK-21427_WORKFLOW-Deploy_JOB-build-worker
TASK-21426_WORKFLOW-Deploy_JOB-build-backend
Обе идут бок о бок. Forgejo 10.0.3 (gitea-1.22), runner v6.3.1 — workflow-level
concurrency здесь не исполняется. Значит и прежние deploy-prod /
deploy-tradein-prod никогда ничего не делали: причиной гонки было не различие
имён групп, а отсутствие взаимного исключения как такового.
Отдельно — flock я в #2952 отверг по неверному основанию. Я написал, что при
аварийной смерти job'а лок залипает. Перепроверил на настоящем сценарии (обрыв
ssh-сессии, а не kill -9 родителя в отрыве): лок держит живой потомок скрипта —
/run/lock/gendesign-docker-deploy.lock:
gendesign 1968950 F.... bash
gendesign 1968953 F.... sleep
но ведь и докер-команды после обрыва сессии продолжают работать на хосте, так
что отпускать лок в этот момент как раз НЕЛЬЗЯ. Это не дефект, а нужная
семантика: исключение действует ровно пока жив тот, кто мутирует докер.
Правка: обе докер-секции берут общий лок на хосте перед работой. Ожидание
ограничено 900с и падает с сообщением, где написано, чем посмотреть держателя.
Второй ssh-шаг (перезагрузка прокси) лок не берёт — он образов не тянет, пруну
там нечего портить.
Секция concurrency оставлена: заработает при обновлении Forgejo. Но гейт теперь
не выдаёт её за действующий механизм — проверки разделены на обязательные (лок)
и декларативные (группа), и в шапке написано, почему.
Гейт мутационно проверен: убрать flock → 2 failed, развести пути локов →
2 failed, убрать сообщение о таймауте → 1 failed, развести группы → 1 failed,
контроль → 7 passed rc=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
