chore(deploy): триггерить деплой на правку ops/docker-prune.sh #2888

Merged

lekss361 merged 1 commit from chore/deploy-trigger-ops-prune into main

2026-08-15 14:15:22 +00:00

lekss361 commented

2026-08-15 14:14:32 +00:00

Owner

Проблема

Довесок к #2887 — нашёл сразу после мержа, проверяя, доехал ли скрипт до прода.

ops/docker-prune.sh исполняется на VM по cron из /opt/gendesign/ops/. Файлы туда попадают единственным путём — шагом git reset --hard origin/main внутри deploy.yml.

Но paths-фильтр deploy.yml перечисляет подпути ops/ поимённо, а не ops/**:

- "ops/glitchtip-auth-forwarder/**"
- "ops/db-bootstrap/**"

#2887 тронул только ops/docker-prune.sh и .forgejo/workflows/ci*.yml — ни один из двух деплой-workflow не сматчился. Проверено на проде после мержа:

$ ssh gendesign 'cd /opt/gendesign && git log --oneline -1 && ls ops/'
f3205d3b fix(tradein/cian): ...        <- прод остался на коммите ДО #2887
backup.sh  db-bootstrap  ...           <- docker-prune.sh отсутствует

При этом cron уже стоял и указывал в пустоту:

0 4 * * 0 bash /opt/gendesign/ops/docker-prune.sh >> ...

Правки скрипта и дальше доезжали бы только случайно — со следующим чужим коммитом в backend/ или data/sql/.

Это уже второй раз

Ровно тот же класс бага уже ловили на ops/db-bootstrap/** — рядом в файле стоит комментарий с той же формулировкой: «без этого триггера правка bootstrap-файла молча не доезжала бы до прода до следующего чужого коммита в backend/».

Что сделано

ops/docker-prune.sh добавлен в paths: deploy.yml по образцу db-bootstrap.
В .claude/rules/deploy.md — явное предупреждение, что ops/** целиком не триггерит, и любой новый исполняемый на VM файл в ops/ надо вносить в paths: руками. Чтобы не наступить на это третий раз.

Прод уже починен вручную

Не стал ждать деплоя — скрипт доставлен из git (не копипастой, чтобы не было расхождения с main):

$ ssh gendesign 'cd /opt/gendesign && git show origin/main:ops/docker-prune.sh > ops/docker-prune.sh && chmod +x ops/docker-prune.sh'
$ DRY_RUN=1 bash ops/docker-prune.sh
старт: диск занят 68%
остановленных контейнеров всего (удалятся только старше 24h): 0
висячих образов: 0
томов-сирот известных форм нет
готово: диск занят 68% (было 68%)

Cron в воскресенье отработает штатно. Ближайший git reset --hard перезапишет файл тем же содержимым — расхождения нет.

Test plan

check yaml в pre-commit прошёл
после мержа — деплой должен запуститься (в отличие от #2887) и принести файл в /opt/gendesign/ops/ уже штатным путём

Что осталось за рамками

docker-prune.sh удаляет только остановленные контейнеры. На проде висят три job-контейнера runner'а в статусе Up возрастом 4-8 недель (FORGEJO-ACTIONS-TASK-7610_...JOB-build-frontend и два ...JOB-changes) — они держат память и под текущую уборку не попадают. Это отдельная проблема, разбирается отдельно.

## Проблема Довесок к #2887 — нашёл сразу после мержа, проверяя, доехал ли скрипт до прода. `ops/docker-prune.sh` исполняется на VM по cron из `/opt/gendesign/ops/`. Файлы туда попадают единственным путём — шагом `git reset --hard origin/main` внутри `deploy.yml`. Но paths-фильтр `deploy.yml` перечисляет подпути `ops/` **поимённо**, а не `ops/**`: ```yaml - "ops/glitchtip-auth-forwarder/**" - "ops/db-bootstrap/**" ``` `#2887` тронул только `ops/docker-prune.sh` и `.forgejo/workflows/ci*.yml` — **ни один** из двух деплой-workflow не сматчился. Проверено на проде после мержа: ``` $ ssh gendesign 'cd /opt/gendesign && git log --oneline -1 && ls ops/' f3205d3b fix(tradein/cian): ... <- прод остался на коммите ДО #2887 backup.sh db-bootstrap ... <- docker-prune.sh отсутствует ``` При этом cron уже стоял и указывал в пустоту: ``` 0 4 * * 0 bash /opt/gendesign/ops/docker-prune.sh >> ... ``` Правки скрипта и дальше доезжали бы только случайно — со следующим чужим коммитом в `backend/` или `data/sql/`. ## Это уже второй раз Ровно тот же класс бага уже ловили на `ops/db-bootstrap/**` — рядом в файле стоит комментарий с той же формулировкой: «без этого триггера правка bootstrap-файла молча не доезжала бы до прода до следующего чужого коммита в backend/». ## Что сделано 1. `ops/docker-prune.sh` добавлен в `paths:` `deploy.yml` по образцу `db-bootstrap`. 2. В `.claude/rules/deploy.md` — явное предупреждение, что `ops/**` целиком **не** триггерит, и любой новый исполняемый на VM файл в `ops/` надо вносить в `paths:` руками. Чтобы не наступить на это третий раз. ## Прод уже починен вручную Не стал ждать деплоя — скрипт доставлен из git (не копипастой, чтобы не было расхождения с main): ``` $ ssh gendesign 'cd /opt/gendesign && git show origin/main:ops/docker-prune.sh > ops/docker-prune.sh && chmod +x ops/docker-prune.sh' $ DRY_RUN=1 bash ops/docker-prune.sh старт: диск занят 68% остановленных контейнеров всего (удалятся только старше 24h): 0 висячих образов: 0 томов-сирот известных форм нет готово: диск занят 68% (было 68%) ``` Cron в воскресенье отработает штатно. Ближайший `git reset --hard` перезапишет файл тем же содержимым — расхождения нет. ## Test plan - [x] `check yaml` в pre-commit прошёл - [ ] после мержа — деплой должен **запуститься** (в отличие от #2887) и принести файл в `/opt/gendesign/ops/` уже штатным путём ## Что осталось за рамками `docker-prune.sh` удаляет только **остановленные** контейнеры. На проде висят три job-контейнера runner'а в статусе `Up` возрастом 4-8 недель (`FORGEJO-ACTIONS-TASK-7610_...JOB-build-frontend` и два `...JOB-changes`) — они держат память и под текущую уборку не попадают. Это отдельная проблема, разбирается отдельно.

lekss361 added 1 commit 2026-08-15 14:14:33 +00:00

chore(deploy): триггерить деплой на правку ops/docker-prune.sh

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

Details

CI / changes (pull_request) Successful in 9s

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 / backend-tests (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

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

Details

c0782a8c4c

Скрипт уборки docker-мусора (#2887) исполняется на прод-VM по cron из
/opt/gendesign/ops/. Файлы туда попадают единственным путём — шагом
`git reset --hard origin/main` внутри deploy.yml.

Но paths-фильтр deploy.yml перечисляет подпути ops/ поимённо, а не ops/**.
Поэтому мерж #2887 деплой НЕ запустил: скрипт остался в main, на VM его не
было, а установленный cron указывал в пустоту. Правки скрипта и дальше
доезжали бы только случайно — со следующим чужим коммитом в backend/.

Ровно этот же баг уже ловили на ops/db-bootstrap/** — там рядом стоит
комментарий с той же формулировкой. Добавляю ops/docker-prune.sh по образцу
и фиксирую грабли в rules/deploy.md, чтобы следующий исполняемый файл в ops/
не наступил на них третий раз.