name: Deploy # Forgejo Actions equivalent of .github/workflows/deploy.yml # Migration 2026-05-16: GitHub → Forgejo (git.gendsgn.ru) # Builds images on Forgejo runner, pushes to ghcr.io (GitHub Container Registry), # SSH-deploys to Beget VPS (46.173.16.127). on: push: branches: [main] paths: - "backend/**" - "frontend/**" - "docker-compose.prod.yml" - "Caddyfile" - "caddy/**" - ".forgejo/workflows/deploy.yml" - "data/sql/**" - "ops/glitchtip-auth-forwarder/**" # Bootstrap-SQL (создание БД auth, ALTER ROLE паролем из env) исполняется шагом # деплоя ниже — без этого триггера правка bootstrap-файла молча не доезжала бы # до прода до следующего чужого коммита в backend/. - "ops/db-bootstrap/**" # RBAC roles config (auth/roles.yaml, bind-mounted read-only ТОЛЬКО в backend — # см. docker-compose.prod.yml; worker монтирует лишь ./data и ./reports). # app.core.auth кэширует парсинг на весь lifetime процесса (@lru_cache) — без # этого триггера правка ролей вступала бы в силу в случайный момент, только на # следующий чужой деплой (`up -d --force-recreate --no-deps backend worker beat` # ниже сбрасывает кэш перезапуском процесса; сам файл в образ не запекается, # ребилда картинок для этого не нужно). - "auth/**" # То же самое, ровно тот же класс бага (#2887): скрипт запускается на VM # по cron из /opt/gendesign/ops/, куда попадает только через `git reset --hard` # шага деплоя. Без этой строки правка скрипта лежала бы в main, а cron месяцами # исполнял бы старую версию — молча и без единого сигнала. # Глоб, а не точечный список (#2203): класс бага — «любой ops-скрипт, # запускаемый по cron с VM», не только docker-prune.sh. Сейчас сюда попадают # backup.sh, restore-drill.sh, restore.sh, uptime-healthcheck.sh — точечное # перечисление пришлось бы дополнять при каждом новом скрипте, и про это # снова забыли бы (см. как этот самый комментарий выше был точечным про # docker-prune.sh и не спас backup.sh). Глоб закрывает класс целиком. - "ops/*.sh" workflow_dispatch: # #2950: ОБЩАЯ группа с deploy-tradein.yml — не опечатка и не копипаста. # Оба деплоя ходят по SSH в ОДИН докер-демон (стеки gendesign-* и tradein-* # плюс сам forgejo-runner живут на одной VM), и `docker image prune -af` одного # сносит leases ещё не доехавшего `compose pull` другого: # unable to lease content: lease does not exist: not found # 20.08 так и вышло: run 8083 упал за 5с — прун соседнего деплоя отработал через # 0.4с после обрыва пула. Прод остался на старом коде, при том что голова main # показывала success (зелёным был чужой, Trade-In'овый деплой той же головы). # Разные группы + cancel-in-progress: false не спасают: false сериализует раны # ВНУТРИ группы, а гонка была МЕЖДУ группами. # Цена: деплои ждут друг друга целиком, вместе с билдами (~6 мин). Осознанно: # host-lock (flock) сериализовал бы только докер-секцию, но у него своя отказная # мода — дочерний процесс наследует fd лока и при аварийной смерти job'а лок # залипает (проверено на хосте: после kill -9 лок остался занят). Сериализацию # гарантирует планировщик Forgejo, залипать там нечему. concurrency: group: deploy-prod cancel-in-progress: false env: IMAGE_BACKEND: ghcr.io/lekss361/gendesign-backend IMAGE_WORKER: ghcr.io/lekss361/gendesign-worker IMAGE_FRONTEND: ghcr.io/lekss361/gendesign-frontend jobs: changes: runs-on: ubuntu-latest outputs: backend: ${{ steps.filter.outputs.backend }} frontend: ${{ steps.filter.outputs.frontend }} infra: ${{ steps.filter.outputs.infra }} # #2916: правка ТОЛЬКО конфига прокси. `infra` для этого не годится — он # включает и compose, и сам workflow, где полный деплой обязателен. # `github.event_name == 'push'` первым множителем НАМЕРЕННО: на # workflow_dispatch у paths-filter нет диффа, и любой его ответ не должен # уметь отключить сборку — ручной прогон обязан оставаться полным. caddy_only: ${{ github.event_name == 'push' && steps.filter.outputs.caddy == 'true' && steps.filter.outputs.non_caddy == 'false' }} steps: - uses: actions/checkout@v4 - uses: dorny/paths-filter@v3 id: filter with: filters: | backend: - 'backend/**' - 'data/sql/**' frontend: - 'frontend/**' infra: - 'docker-compose.prod.yml' - 'Caddyfile' - 'caddy/**' - '.forgejo/workflows/deploy.yml' # Пара фильтров для «правка ТОЛЬКО прокси» (#2916). Одного `caddy` # мало: он true и когда вместе с конфигом приехал бэкенд — тогда # нужен обычный полный деплой. `non_caddy` матчит ВСЁ остальное, # и быстрый путь включается лишь когда он false. caddy: - 'Caddyfile' - 'caddy/**' non_caddy: - '**' - '!Caddyfile' - '!caddy/**' build-backend: runs-on: ubuntu-latest needs: changes if: | needs.changes.outputs.caddy_only != 'true' && ( needs.changes.outputs.backend == 'true' || needs.changes.outputs.infra == 'true' || github.event_name == 'workflow_dispatch' ) steps: - uses: actions/checkout@v4 - name: Login to GHCR (shell-based — docker/login-action@v3 unreliable под Forgejo Actions) env: GHCR_PAT: ${{ secrets.GHCR_PAT }} run: | echo "$GHCR_PAT" | docker login ghcr.io -u lekss361 --password-stdin - name: Подобрать протёкшие buildx-билдеры (#2869) # Билдеры протекают НЕ на обычном падении, а когда job умирает аварийно # (ENOSPC, OOM, отмена concurrency-группой): тогда ни post-step действия, # ни завершающий шаг не выполняются — контейнер job'а уже мёртв. # Замер 13.08: 20 висящих билдеров, созданных в 8 дат за три месяца # (17.05, 30.05, 31.05, 13.06, 17.06, 20.06, 28.06, 05.07) — и ни одного # за пять недель между 05.07 и 13.08, когда аварий не было. Два последних # созданы 13.08 11:57:43 — ровно тот прогон, что упал с # `no space left on device`. # Поэтому чистим ЧУЖОЙ мусор НА ВХОДЕ: всё старше 6 часов заведомо не # принадлежит живому прогону (самый долгий job — ~17 минут). run: | now=$(date +%s); reaped=0; kept=0 for c in $(docker ps -a --filter "name=^buildx_buildkit_builder-" --format '{{.Names}}'); do created=$(docker inspect "$c" --format '{{.Created}}' 2>/dev/null) || continue ts=$(date -d "$created" +%s 2>/dev/null) || continue age_h=$(( (now - ts) / 3600 )) if [ "$age_h" -ge 6 ]; then echo "buildx: убираю протёкший билдер $c (возраст ${age_h} ч)" if docker rm -f "$c" >/dev/null 2>&1; then reaped=$((reaped+1)) else echo "buildx: не удалось убрать $c (не фатально)" fi docker volume rm "${c}_state" >/dev/null 2>&1 || true else kept=$((kept+1)) fi done echo "buildx: убрано протёкших ${reaped}, оставлено свежих ${kept}" df -h / | tail -1 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 id: buildx - name: Build & push backend (lean — без Chromium) # id + continue-on-error: битый blob в удалённом buildcache-манифесте # (registry cache, не local) валит весь шаг ДО push нового образа — # деплой тогда молча пропускается (#2841), хотя код собрать можно, просто # без кеша. cache-from нефатален: при падении ретраим БЕЗ него ниже. id: build continue-on-error: true uses: docker/build-push-action@v6 with: context: ./backend target: runner push: true labels: | org.opencontainers.image.revision=${{ github.sha }} cache-from: type=registry,ref=${{ env.IMAGE_BACKEND }}:buildcache cache-to: type=registry,ref=${{ env.IMAGE_BACKEND }}:buildcache,mode=max tags: | ${{ env.IMAGE_BACKEND }}:latest ${{ env.IMAGE_BACKEND }}:${{ github.sha }} - name: Retry build & push backend без кеша (битый buildcache, #2841) # cache-from опущен (источник падения), а cache-to ОСТАВЛЕН: успешный # ретрай пушит свежие слои в buildcache-тег и тем самым сам перезаписывает # битый blob (mode=max — полная перезапись манифеста). Раньше cache-to был # опущен и здесь тоже — но следующий обычный прогон опять получает cache-from # на детерминированно битый тег и падает СНОВА: самолечения не было НИКОГДА # (ревью #2841 R2, issue #2). Если и retry упадёт — шаг красный БЕЗ # continue-on-error, job честно FAILURE, и deploy ниже корректно # пропускается (уже настоящая причина, не кеш). if: steps.build.outcome == 'failure' uses: docker/build-push-action@v6 with: context: ./backend target: runner push: true labels: | org.opencontainers.image.revision=${{ github.sha }} cache-to: type=registry,ref=${{ env.IMAGE_BACKEND }}:buildcache,mode=max tags: | ${{ env.IMAGE_BACKEND }}:latest ${{ env.IMAGE_BACKEND }}:${{ github.sha }} - name: Проверить, что backend:${{ github.sha }} реально в registry (fail-safe, #2841 R2) # НЕ полагается на семантику steps.build.outcome/continue-on-error раннера — # проверяет РЕАЛЬНОЕ состояние registry напрямую через buildx (уже настроен # выше). Если act_runner не заполняет outcome (не проверено живым прогоном, # см. ревью), ретрай выше молча НЕ побежит при упавшем build, а этот шаг — # единственный, кто это заметит: манифеста с этим SHA не будет → шаг падает # БЕЗ continue-on-error → job честно FAILURE → deploy ниже пропускается # вместо накатки старого :latest на прод. run: docker buildx imagetools inspect ${{ env.IMAGE_BACKEND }}:${{ github.sha }} > /dev/null - name: Убрать buildx-билдер (#2869 — иначе копятся по одному на прогон) # setup-buildx-action создаёт билдер `docker-container` на КАЖДЫЙ прогон. # Его post-step под Forgejo act_runner не срабатывает, поэтому к 13.08 на # хосте накопилось 20 контейнеров возрастом до двух месяцев и ~19 ГБ в # их `_state`-томах — диск ушёл на 94%, деплой упал с # `no space left on device`. Убираем явно, `if: always()` и `|| true`, # чтобы уборка не могла уронить прогон. if: always() run: | name="${{ steps.buildx.outputs.name }}" if [ -z "$name" ]; then echo "buildx: имя билдера не пришло из outputs — уборка НЕ сработала (см. #2869)" exit 0 fi echo "buildx: убираю билдер $name" docker buildx rm --force "$name" || echo "buildx: не удалось убрать $name (не фатально)" build-worker: runs-on: ubuntu-latest needs: changes if: | needs.changes.outputs.caddy_only != 'true' && ( needs.changes.outputs.backend == 'true' || needs.changes.outputs.infra == 'true' || github.event_name == 'workflow_dispatch' ) steps: - uses: actions/checkout@v4 - name: Login to GHCR (shell-based — docker/login-action@v3 unreliable под Forgejo Actions) env: GHCR_PAT: ${{ secrets.GHCR_PAT }} run: | echo "$GHCR_PAT" | docker login ghcr.io -u lekss361 --password-stdin - name: Подобрать протёкшие buildx-билдеры (#2869) # Билдеры протекают НЕ на обычном падении, а когда job умирает аварийно # (ENOSPC, OOM, отмена concurrency-группой): тогда ни post-step действия, # ни завершающий шаг не выполняются — контейнер job'а уже мёртв. # Замер 13.08: 20 висящих билдеров, созданных в 8 дат за три месяца # (17.05, 30.05, 31.05, 13.06, 17.06, 20.06, 28.06, 05.07) — и ни одного # за пять недель между 05.07 и 13.08, когда аварий не было. Два последних # созданы 13.08 11:57:43 — ровно тот прогон, что упал с # `no space left on device`. # Поэтому чистим ЧУЖОЙ мусор НА ВХОДЕ: всё старше 6 часов заведомо не # принадлежит живому прогону (самый долгий job — ~17 минут). run: | now=$(date +%s); reaped=0; kept=0 for c in $(docker ps -a --filter "name=^buildx_buildkit_builder-" --format '{{.Names}}'); do created=$(docker inspect "$c" --format '{{.Created}}' 2>/dev/null) || continue ts=$(date -d "$created" +%s 2>/dev/null) || continue age_h=$(( (now - ts) / 3600 )) if [ "$age_h" -ge 6 ]; then echo "buildx: убираю протёкший билдер $c (возраст ${age_h} ч)" if docker rm -f "$c" >/dev/null 2>&1; then reaped=$((reaped+1)) else echo "buildx: не удалось убрать $c (не фатально)" fi docker volume rm "${c}_state" >/dev/null 2>&1 || true else kept=$((kept+1)) fi done echo "buildx: убрано протёкших ${reaped}, оставлено свежих ${kept}" df -h / | tail -1 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 id: buildx - name: Build & push worker (с Chromium для Playwright) # id + continue-on-error — см. build-backend выше (#2841): битый blob в # удалённом buildcache не должен ронять сборку и молча пропускать деплой. id: build continue-on-error: true uses: docker/build-push-action@v6 with: context: ./backend target: runner-with-chromium push: true labels: | org.opencontainers.image.revision=${{ github.sha }} cache-from: type=registry,ref=${{ env.IMAGE_WORKER }}:buildcache cache-to: type=registry,ref=${{ env.IMAGE_WORKER }}:buildcache,mode=max tags: | ${{ env.IMAGE_WORKER }}:latest ${{ env.IMAGE_WORKER }}:${{ github.sha }} - name: Retry build & push worker без кеша (битый buildcache, #2841) # См. backend (issue #2, ревью R2): cache-from опущен, cache-to ОСТАВЛЕН — # успешный ретрай перезаписывает битый buildcache-тег своими слоями # (mode=max), это и есть самолечение. Без cache-to здесь порча оставалась # навсегда — следующий прогон снова падал на том же cache-from. if: steps.build.outcome == 'failure' uses: docker/build-push-action@v6 with: context: ./backend target: runner-with-chromium push: true labels: | org.opencontainers.image.revision=${{ github.sha }} cache-to: type=registry,ref=${{ env.IMAGE_WORKER }}:buildcache,mode=max tags: | ${{ env.IMAGE_WORKER }}:latest ${{ env.IMAGE_WORKER }}:${{ github.sha }} - name: Проверить, что worker:${{ github.sha }} реально в registry (fail-safe, #2841 R2) # См. backend выше — не полагается на steps.build.outcome раннера, проверяет # реальное состояние registry, чтобы молча пропущенный ретрай (если outcome # не поддержан) честно уронил job вместо зелёного прогона с непушнутым образом. run: docker buildx imagetools inspect ${{ env.IMAGE_WORKER }}:${{ github.sha }} > /dev/null - name: Убрать buildx-билдер (#2869 — иначе копятся по одному на прогон) # setup-buildx-action создаёт билдер `docker-container` на КАЖДЫЙ прогон. # Его post-step под Forgejo act_runner не срабатывает, поэтому к 13.08 на # хосте накопилось 20 контейнеров возрастом до двух месяцев и ~19 ГБ в # их `_state`-томах — диск ушёл на 94%, деплой упал с # `no space left on device`. Убираем явно, `if: always()` и `|| true`, # чтобы уборка не могла уронить прогон. if: always() run: | name="${{ steps.buildx.outputs.name }}" if [ -z "$name" ]; then echo "buildx: имя билдера не пришло из outputs — уборка НЕ сработала (см. #2869)" exit 0 fi echo "buildx: убираю билдер $name" docker buildx rm --force "$name" || echo "buildx: не удалось убрать $name (не фатально)" build-frontend: runs-on: ubuntu-latest needs: changes if: | needs.changes.outputs.caddy_only != 'true' && ( needs.changes.outputs.frontend == 'true' || needs.changes.outputs.infra == 'true' || github.event_name == 'workflow_dispatch' ) steps: - uses: actions/checkout@v4 - name: Login to GHCR (shell-based — docker/login-action@v3 unreliable под Forgejo Actions) env: GHCR_PAT: ${{ secrets.GHCR_PAT }} run: | echo "$GHCR_PAT" | docker login ghcr.io -u lekss361 --password-stdin - name: Подобрать протёкшие buildx-билдеры (#2869) # Билдеры протекают НЕ на обычном падении, а когда job умирает аварийно # (ENOSPC, OOM, отмена concurrency-группой): тогда ни post-step действия, # ни завершающий шаг не выполняются — контейнер job'а уже мёртв. # Замер 13.08: 20 висящих билдеров, созданных в 8 дат за три месяца # (17.05, 30.05, 31.05, 13.06, 17.06, 20.06, 28.06, 05.07) — и ни одного # за пять недель между 05.07 и 13.08, когда аварий не было. Два последних # созданы 13.08 11:57:43 — ровно тот прогон, что упал с # `no space left on device`. # Поэтому чистим ЧУЖОЙ мусор НА ВХОДЕ: всё старше 6 часов заведомо не # принадлежит живому прогону (самый долгий job — ~17 минут). run: | now=$(date +%s); reaped=0; kept=0 for c in $(docker ps -a --filter "name=^buildx_buildkit_builder-" --format '{{.Names}}'); do created=$(docker inspect "$c" --format '{{.Created}}' 2>/dev/null) || continue ts=$(date -d "$created" +%s 2>/dev/null) || continue age_h=$(( (now - ts) / 3600 )) if [ "$age_h" -ge 6 ]; then echo "buildx: убираю протёкший билдер $c (возраст ${age_h} ч)" if docker rm -f "$c" >/dev/null 2>&1; then reaped=$((reaped+1)) else echo "buildx: не удалось убрать $c (не фатально)" fi docker volume rm "${c}_state" >/dev/null 2>&1 || true else kept=$((kept+1)) fi done echo "buildx: убрано протёкших ${reaped}, оставлено свежих ${kept}" df -h / | tail -1 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 id: buildx - name: Build & push frontend # id + continue-on-error — см. build-backend выше (#2841): битый blob в # удалённом buildcache не должен ронять сборку и молча пропускать деплой. id: build continue-on-error: true uses: docker/build-push-action@v6 with: context: ./frontend push: true labels: | org.opencontainers.image.revision=${{ github.sha }} build-args: | NEXT_PUBLIC_GLITCHTIP_DSN=${{ secrets.GLITCHTIP_FRONTEND_DSN }} NEXT_PUBLIC_ENVIRONMENT=production cache-from: type=registry,ref=${{ env.IMAGE_FRONTEND }}:buildcache cache-to: type=registry,ref=${{ env.IMAGE_FRONTEND }}:buildcache,mode=max tags: | ${{ env.IMAGE_FRONTEND }}:latest ${{ env.IMAGE_FRONTEND }}:${{ github.sha }} - name: Retry build & push frontend без кеша (битый buildcache, #2841) # См. backend (issue #2, ревью R2): cache-from опущен, cache-to ОСТАВЛЕН — # успешный ретрай перезаписывает битый buildcache-тег своими слоями # (mode=max), это и есть самолечение. Без cache-to здесь порча оставалась # навсегда — следующий прогон снова падал на том же cache-from. if: steps.build.outcome == 'failure' uses: docker/build-push-action@v6 with: context: ./frontend push: true labels: | org.opencontainers.image.revision=${{ github.sha }} build-args: | NEXT_PUBLIC_GLITCHTIP_DSN=${{ secrets.GLITCHTIP_FRONTEND_DSN }} NEXT_PUBLIC_ENVIRONMENT=production cache-to: type=registry,ref=${{ env.IMAGE_FRONTEND }}:buildcache,mode=max tags: | ${{ env.IMAGE_FRONTEND }}:latest ${{ env.IMAGE_FRONTEND }}:${{ github.sha }} - name: Проверить, что frontend:${{ github.sha }} реально в registry (fail-safe, #2841 R2) # См. backend выше — не полагается на steps.build.outcome раннера, проверяет # реальное состояние registry, чтобы молча пропущенный ретрай (если outcome # не поддержан) честно уронил job вместо зелёного прогона с непушнутым образом. run: docker buildx imagetools inspect ${{ env.IMAGE_FRONTEND }}:${{ github.sha }} > /dev/null - name: Убрать buildx-билдер (#2869 — иначе копятся по одному на прогон) # setup-buildx-action создаёт билдер `docker-container` на КАЖДЫЙ прогон. # Его post-step под Forgejo act_runner не срабатывает, поэтому к 13.08 на # хосте накопилось 20 контейнеров возрастом до двух месяцев и ~19 ГБ в # их `_state`-томах — диск ушёл на 94%, деплой упал с # `no space left on device`. Убираем явно, `if: always()` и `|| true`, # чтобы уборка не могла уронить прогон. if: always() run: | name="${{ steps.buildx.outputs.name }}" if [ -z "$name" ]; then echo "buildx: имя билдера не пришло из outputs — уборка НЕ сработала (см. #2869)" exit 0 fi echo "buildx: убираю билдер $name" docker buildx rm --force "$name" || echo "buildx: не удалось убрать $name (не фатально)" deploy: runs-on: ubuntu-latest needs: [changes, build-backend, build-worker, build-frontend] if: | always() && !cancelled() && needs.changes.outputs.caddy_only != 'true' && needs.build-backend.result != 'failure' && needs.build-worker.result != 'failure' && needs.build-frontend.result != 'failure' steps: # ── #2950: :latest не старше последнего коммита по компоненту ───────────── # Forgejo отменяет ещё не стартовавший deploy предыдущего run'а этой группы, # а следующий run (например ops-only, билды пропущены) катит :latest как есть. # 21.08.2026 10:35 прод получил новый код только потому, что билды # предшественника успели за 70 с до pull'а. Гард читает метку ревизии из # образа в registry (labels на build-push выше), ждёт билд предшественника # до 15 мин и иначе падает громко — вместо тихого отката при зелёной голове. # Пути = фильтры job'а changes, которые приводят к сборке (caddy_only не # собирает — Caddyfile/caddy/** намеренно не в списке). - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Login to GHCR — для imagetools inspect гарда (#2950) env: GHCR_PAT: ${{ secrets.GHCR_PAT }} run: echo "$GHCR_PAT" | docker login ghcr.io -u lekss361 --password-stdin - name: Гард свежести :latest (#2950) run: | INFRA="docker-compose.prod.yml .forgejo/workflows/deploy.yml" scripts/check-latest-image-revision.sh "$IMAGE_BACKEND" 900 -- backend data/sql $INFRA scripts/check-latest-image-revision.sh "$IMAGE_WORKER" 900 -- backend data/sql $INFRA scripts/check-latest-image-revision.sh "$IMAGE_FRONTEND" 900 -- frontend $INFRA - name: Deploy to VM via SSH uses: appleboy/ssh-action@v1.0.3 env: IMAGE_TAG: latest SENTRY_RELEASE_VAL: ${{ github.sha }} GHCR_PAT: ${{ secrets.GHCR_PAT }} GLITCHTIP_BACKEND_DSN: ${{ secrets.GLITCHTIP_BACKEND_DSN }} OBJECTIVE_API_KEY: ${{ secrets.OBJECTIVE_API_KEY }} # LLM chat (#960/#957): оба UNSET по умолчанию → feature dormant # (settings.llm_enabled=False, settings.openai_api_key=None). # OPENAI_API_KEY — sensitive → secret. LLM_ENABLED — non-sensitive # boolean toggle → actions variable (vars.*). OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} LLM_ENABLED: ${{ vars.LLM_ENABLED }} # OWN_DEVELOPER_IDS (#1169 §25.3): свои developer_id (companyGroup) для # own-portfolio каннибализации. Non-sensitive (публичные id) → actions # variable. UNSET → каннибализация отдаёт proxy (фича дормант). OWN_DEVELOPER_IDS: ${{ vars.OWN_DEVELOPER_IDS }} with: host: ${{ secrets.DEPLOY_HOST }} username: ${{ secrets.DEPLOY_USER }} key: ${{ secrets.DEPLOY_SSH_KEY }} port: ${{ secrets.DEPLOY_PORT }} envs: IMAGE_TAG,SENTRY_RELEASE_VAL,GHCR_PAT,GLITCHTIP_BACKEND_DSN,OBJECTIVE_API_KEY,OPENAI_API_KEY,LLM_ENABLED,OWN_DEVELOPER_IDS script: | set -euo pipefail # #2950: взаимное исключение докер-секции двух прод-деплоев. # Деплой ПТИЦЫ и деплой Trade-In ходят по SSH в ОДИН докер-демон — # стеки gendesign-*, tradein-* и сам forgejo-runner живут на этой VM. # Каждый в конце делает `docker image prune -af`, и прун одного сносит # leases ещё не доехавшего `compose pull` другого: # unable to lease content: lease does not exist: not found # 20.08 так и вышло: run 8083 упал за 5с (прун соседа отработал через # 0.4с после обрыва пула), прод остался на старом коде. # # Секция `concurrency: deploy-prod` в шапке обоих workflow этого НЕ # обеспечивает: на Forgejo 10.0.3 (gitea-1.22) workflow-level # concurrency не исполняется — проверено, обе цепочки стартовали на # одном коммите одновременно. Она оставлена как декларация, которая # заработает после обновления Forgejo; сегодня работает вот этот лок. # # Лок держит живой потомок этого скрипта. Если ssh-сессия оборвётся, # докер-команды на хосте продолжат работу — и лок продолжит их # прикрывать, что и требуется. Ожидание ограничено: не дождались за # 900с — падаем с внятным сообщением, а не молча ждём вечно. exec 9>/var/lock/gendesign-docker-deploy.lock # Сначала неблокирующая попытка — чтобы ОЖИДАНИЕ оставляло след в логе. # Без этого работающий лок ненаблюдаем: flock при успехе молчит, и отличить # «второй деплой дождался первого» от «они просто разошлись по времени» # нельзя — а именно это и есть критерий приёмки #2950. if flock -n 9; then echo "→ докер-лок свободен, взят сразу" else echo "→ докер-лок занят соседним деплоем, жду (до 900с)…" lock_wait_started=$(date +%s) if ! flock -w 900 9; then echo "ERROR: не дождался лока докер-деплоя за 900с." echo " Кто держит: ssh на хост, затем fuser -v /var/lock/gendesign-docker-deploy.lock" exit 1 fi echo "→ докер-лок получен через $(( $(date +%s) - lock_wait_started ))с ожидания" fi cd /opt/gendesign # Sync compose / Caddyfile / init scripts from the repo. # Origin теперь Forgejo (после migration 2026-05-16) — HTTPS basic auth # через PAT в URL не нужен т.к. repo читается через deploy key (SSH) # ИЛИ public read-only mode. Forgejo gendesign — private, нужен auth: # `git remote get-url origin` должен указывать на Forgejo с auth. git fetch origin main git reset --hard origin/main # Re-assert +x on ops scripts (#71). These are committed 100755, so a # reset normally preserves the bit — but this is belt-and-suspenders so # a script that ever lands as 644 can't silently break its cron caller # (cron `30 3 * * * bash /opt/gendesign/ops/backup.sh` is +x-independent, # but other callers may invoke the raw path). chmod +x ops/*.sh 2>/dev/null || true # Full PDF report bind-source (#2259 PR-D). docker создаёт отсутствующий # bind-source как root:root — worker пишет PDF под uid 1000 → PermissionError # → вечный «building». Создаём каталог заранее + chown под контейнерный uid. # chown под non-root deploy-юзером требует sudo → fallback (|| true — если и # sudo нет, каталог уже наш и chown не нужен). mkdir -p reports chown 1000:1000 reports 2>/dev/null || sudo chown 1000:1000 reports 2>/dev/null || true # Sentry release tracking mkdir -p backend touch backend/.env.runtime if grep -q '^SENTRY_RELEASE=' backend/.env.runtime; then sed -i "s|^SENTRY_RELEASE=.*|SENTRY_RELEASE=$SENTRY_RELEASE_VAL|" backend/.env.runtime else printf 'SENTRY_RELEASE=%s\n' "$SENTRY_RELEASE_VAL" >> backend/.env.runtime fi # GlitchTip wiring: убираем legacy SENTRY_DSN (auto-promote-логика в # backend/app/core/config.py:_promote_legacy_sentry_dsn раньше брала # его и слала события в чужой sentry.io). Устанавливаем GLITCHTIP_DSN # из Forgejo secret. Пустой secret = no-op (SDK не инициализируется). sed -i '/^SENTRY_DSN=/d' backend/.env.runtime if grep -q '^GLITCHTIP_DSN=' backend/.env.runtime; then sed -i "s|^GLITCHTIP_DSN=.*|GLITCHTIP_DSN=$GLITCHTIP_BACKEND_DSN|" backend/.env.runtime else printf 'GLITCHTIP_DSN=%s\n' "$GLITCHTIP_BACKEND_DSN" >> backend/.env.runtime fi # Objective API key — для live scraper sync_all_groups (issue #307 OBJ-1). # Пустой secret = no-op (sync_objective_group skipped с reason=no_api_key). if grep -q '^OBJECTIVE_API_KEY=' backend/.env.runtime; then sed -i "s|^OBJECTIVE_API_KEY=.*|OBJECTIVE_API_KEY=$OBJECTIVE_API_KEY|" backend/.env.runtime else printf 'OBJECTIVE_API_KEY=%s\n' "$OBJECTIVE_API_KEY" >> backend/.env.runtime fi # LLM chat (#960/#957) — OpenAI key + enable toggle. В ОТЛИЧИЕ от # OBJECTIVE_API_KEY пишем ТОЛЬКО при non-empty value: если Forgejo # secret/var UNSET — ничего не пишем, app держит safe defaults # (settings.llm_enabled=False, settings.openai_api_key=None) → feature # dormant, без мусорной пустой строки `OPENAI_API_KEY=` в .env.runtime. if [ -n "${OPENAI_API_KEY:-}" ]; then if grep -q '^OPENAI_API_KEY=' backend/.env.runtime; then sed -i "s|^OPENAI_API_KEY=.*|OPENAI_API_KEY=$OPENAI_API_KEY|" backend/.env.runtime else printf 'OPENAI_API_KEY=%s\n' "$OPENAI_API_KEY" >> backend/.env.runtime fi fi if [ -n "${LLM_ENABLED:-}" ]; then if grep -q '^LLM_ENABLED=' backend/.env.runtime; then sed -i "s|^LLM_ENABLED=.*|LLM_ENABLED=$LLM_ENABLED|" backend/.env.runtime else printf 'LLM_ENABLED=%s\n' "$LLM_ENABLED" >> backend/.env.runtime fi fi # OWN_DEVELOPER_IDS (#1169 §25.3 own-portfolio каннибализация). Тоже # conditional-on-non-empty: UNSET var → не трогаем (если строка уже есть # в .env.runtime — она переживает git reset, .gitignored — остаётся). if [ -n "${OWN_DEVELOPER_IDS:-}" ]; then if grep -q '^OWN_DEVELOPER_IDS=' backend/.env.runtime; then sed -i "s|^OWN_DEVELOPER_IDS=.*|OWN_DEVELOPER_IDS=$OWN_DEVELOPER_IDS|" backend/.env.runtime else printf 'OWN_DEVELOPER_IDS=%s\n' "$OWN_DEVELOPER_IDS" >> backend/.env.runtime fi fi chmod 600 backend/.env.runtime # External network для Caddy + obsidian-stack share docker network inspect gendesign_shared >/dev/null 2>&1 \ || docker network create gendesign_shared # Re-login to GHCR (PAT может быть rotated после initial setup) echo "$GHCR_PAT" | docker login ghcr.io -u lekss361 --password-stdin export IMAGE_TAG="$IMAGE_TAG" docker compose -p gendesign -f docker-compose.prod.yml pull # Apply pending SQL migrations set -a; source .env; set +a docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -v ON_ERROR_STOP=on -c " CREATE TABLE IF NOT EXISTS _schema_migrations ( filename TEXT PRIMARY KEY, applied_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); " for sql_file in $(ls -1 data/sql/*.sql 2>/dev/null | sort); do fname=$(basename "$sql_file") applied=$(docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -tAc \ "SELECT COUNT(*) FROM _schema_migrations WHERE filename='$fname'") if [ "$applied" = "0" ]; then echo "→ Applying migration: $fname" docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -v ON_ERROR_STOP=on \ < "$sql_file" \ || { echo "FAILED on migration: $fname"; exit 1; } docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c \ "INSERT INTO _schema_migrations (filename) VALUES ('$fname') ON CONFLICT DO NOTHING;" else echo "✓ Already applied: $fname" fi done echo "All migrations applied." # Невалидные индексы после цикла (#2752). Оборванный CREATE INDEX # CONCURRENTLY оставляет индекс с indisvalid=false: планировщик им НЕ # пользуется, а re-run миграции его не чинит — `CREATE INDEX # CONCURRENTLY IF NOT EXISTS` печатает «relation already exists, # skipping» и выходит с кодом 0, после чего миграция помечается # применённой, а индекс остаётся битым навсегда (воспроизведено на # PostgreSQL 16.4). В data/sql 5 файлов с CREATE INDEX CONCURRENTLY. # Одна проверка здесь вместо DO-блока в каждом файле; на 2026-08-07 # на проде таких индексов 0 — это профилактика. invalid_idx=$(docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -tAc \ "SELECT string_agg(i.indexrelid::regclass::text || ' на ' || i.indrelid::regclass::text, ', ') FROM pg_index i JOIN pg_class c ON c.oid = i.indexrelid JOIN pg_namespace n ON n.oid = c.relnamespace WHERE NOT i.indisvalid AND n.nspname NOT IN ('pg_catalog', 'information_schema');" \ | tr -d '\r' | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//') \ || { echo "ERROR: не удалось прочитать pg_index (psql не ответил) — прерываю деплой."; exit 1; } if [ -n "$invalid_idx" ]; then echo "ERROR: в БД есть НЕВАЛИДНЫЕ индексы: $invalid_idx" echo " Это след оборванного CREATE INDEX CONCURRENTLY: планировщик такой" echo " индекс не использует, а re-run миграции с IF NOT EXISTS его не чинит" echo " (тихо пропускает как существующий). Новый app-код НЕ поднят." echo " Лечение вручную на проде: DROP INDEX CONCURRENTLY <имя>; затем" echo " пересоздать индекс и повторить деплой." exit 1 fi echo "✓ невалидных индексов нет." # Set tradein_fdw_reader password from env (post-migration bootstrap). # SQL migration 100_tradein_fdw_role.sql creates role passwordless; # password lives only in /opt/gendesign/backend/.env.runtime. # See ops/db-bootstrap/set_tradein_fdw_password.sql for the idempotent DO block. set -a; source backend/.env.runtime; set +a if [ -n "${GENDESIGN_FDW_PASSWORD:-}" ]; then echo "→ Applying tradein_fdw_reader password from env" docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -v ON_ERROR_STOP=on \ -v "pw=$GENDESIGN_FDW_PASSWORD" \ < ops/db-bootstrap/set_tradein_fdw_password.sql else echo "⚠️ GENDESIGN_FDW_PASSWORD not set in backend/.env.runtime — skipping ALTER ROLE for tradein_fdw_reader" fi # ── БД `auth` — единое хранилище доступов «Меры» и «Птицы» ────────────── # Расположение файлов: схема лежит в data/sql/auth/ (ПОДКАТАЛОГ, не плоский # data/sql/) — цикл миграций выше использует `ls -1 data/sql/*.sql`, который в # подкаталоги не рекурсирует. Значит эти файлы физически не могут примениться # в БД gendesign, даже если кто-то забудет про разделение; при этом триггер # `data/sql/**` (paths выше) подкаталог покрывает, деплой запускается сам. # Свой _schema_migrations живёт ВНУТРИ БД auth: отдельная база — отдельный # трекинг, имена файлов двух каталогов не конфликтуют между собой. # Порядок: сразу после bootstrap'а FDW-пароля и ДО `compose up -d` — падение # здесь останавливает деплой (exit 1) до подъёма нового кода. # `source backend/.env.runtime` уже выполнен выше (строка с FDW-паролем), из него # берётся AUTH_DB_PASSWORD. echo "→ Bootstrapping auth database (idempotent)" docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d postgres -v ON_ERROR_STOP=on \ < ops/db-bootstrap/create_auth_db.sql \ || { echo "FAILED to create auth database"; exit 1; } docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d auth -v ON_ERROR_STOP=on -c " CREATE TABLE IF NOT EXISTS _schema_migrations ( filename TEXT PRIMARY KEY, applied_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); " for sql_file in $(ls -1 data/sql/auth/*.sql 2>/dev/null | sort); do fname=$(basename "$sql_file") # `| tr -d '[:space:]'` — как в deploy-tradein.yml: без него psql-вывод с # лишним пробелом/CR ломает сравнение с "0" и миграция молча считается # применённой. applied=$(docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d auth -tAc \ "SELECT COUNT(*) FROM _schema_migrations WHERE filename='$fname'" \ | tr -d '[:space:]') if [ "$applied" = "0" ]; then echo "→ Applying auth migration: $fname" docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d auth -v ON_ERROR_STOP=on \ < "$sql_file" \ || { echo "FAILED on auth migration: $fname"; exit 1; } docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d auth -c \ "INSERT INTO _schema_migrations (filename) VALUES ('$fname') ON CONFLICT DO NOTHING;" else echo "✓ Already applied (auth): $fname" fi done echo "All auth migrations applied." # Пароль роли auth_app из env (post-migration bootstrap): миграция # data/sql/auth/002_auth_app_role.sql создаёт роль БЕЗ пароля, пароль живёт # только в /opt/gendesign/backend/.env.runtime. Пустая переменная — не ошибка: # PR-1 ещё никого не подключает к этой БД, роль просто остаётся без пароля. if [ -n "${AUTH_DB_PASSWORD:-}" ]; then echo "→ Applying auth_app password from env" docker compose -p gendesign -f docker-compose.prod.yml exec -T postgres \ psql -U "$POSTGRES_USER" -d auth -v ON_ERROR_STOP=on \ -v "pw=$AUTH_DB_PASSWORD" \ < ops/db-bootstrap/set_auth_app_password.sql else echo "⚠️ AUTH_DB_PASSWORD not set in backend/.env.runtime — skipping ALTER ROLE for auth_app" fi # Build local-only sidecar images (glitchtip-auth-forwarder). # Эти services не в GHCR — сборка происходит на VPS на каждом deploy. # Cache-friendly: первый build ~30s, последующие 1-3s если файлы не менялись. docker compose -p gendesign -f docker-compose.prod.yml build glitchtip-auth-forwarder docker compose -p gendesign -f docker-compose.prod.yml up -d # Defense: ensure postgres is in gendesign_shared network for tradein FDW. # `compose up -d` should detect networks: shared addition and recreate # postgres, but in PR #493 deploy/1156 incident the bootstrap step failed # earlier so this code path never ran. Plus compose sometimes skips # recreate if it thinks config is "compatible enough". Verify explicitly. if ! docker inspect gendesign-postgres-1 \ --format '{{range $k,$v := .NetworkSettings.Networks}}{{$k}} {{end}}' \ 2>/dev/null | grep -q gendesign_shared; then echo "⚠️ postgres not in gendesign_shared after compose up — force-recreating" docker compose -p gendesign -f docker-compose.prod.yml up -d \ --force-recreate --no-deps postgres # Brief settle window: backend will reconnect after postgres restart. sleep 5 fi # backend/.env.runtime изменения (SENTRY_RELEASE, GLITCHTIP_DSN) # требуют --force-recreate — обычный `up -d` не перечитывает env_file # если только image не сменился. На deploy где меняется только runtime # без backend image change — без этого backend остаётся со старым DSN. docker compose -p gendesign -f docker-compose.prod.yml up -d \ --force-recreate --no-deps backend worker beat # Caddy: force-recreate чтобы подхватить изменения в Caddyfile # И в особенности новые volume mounts из docker-compose.prod.yml # (`reload` не пересоздаёт container, поэтому новые binds не появляются — # был случай 2026-05-17 с PR #268 preview/ — потребовался manual SSH fix). docker compose -p gendesign -f docker-compose.prod.yml up -d \ --force-recreate --no-deps caddy # Forwarder: force-recreate чтобы новый image / новые env подхватывались. # Без --force-recreate обычный `up -d` НЕ recreate'ит при image rebuild # (т.к. image:latest tag не сменился — docker не видит разницы). docker compose -p gendesign -f docker-compose.prod.yml up -d \ --force-recreate --no-deps glitchtip-auth-forwarder # Cleanup old images for repo in ghcr.io/lekss361/gendesign-backend \ ghcr.io/lekss361/gendesign-worker \ ghcr.io/lekss361/gendesign-frontend; do docker images "$repo" --format '{{.Repository}}:{{.Tag}}' \ | grep -v ':latest$' \ | tail -n +3 \ | xargs -r docker rmi 2>/dev/null || true done docker image prune -af || true docker builder prune -af || true # Health check — деплой ВАЛИТСЯ, если backend не поднялся (см. #2214, # уже сделано так в deploy-tradein.yml; ревью #2841 R2 issue #3). # `curl ... && break` под set -e НЕ мог провалить скрипт: curl — не # последняя команда &&-списка, а POSIX прямо освобождает от errexit # все команды AND/OR-списка кроме последней. После 30 неуспешных # попыток цикл завершался кодом последнего sleep (0) — скрипт тихо # продолжался, деплой уходил success с мёртвым бэкендом. healthy="" for i in $(seq 1 30); do if curl -fsS http://localhost:8000/health >/dev/null 2>&1; then healthy="yes"; break fi sleep 1 done if [ -z "$healthy" ]; then echo "ERROR: backend не ответил на /health за 30s — деплой FAILED" exit 1 fi echo "→ backend healthy на /health." # Честный итог прогона (#2841). ПРОБЛЕМА: `deploy` пропускается своим `if:` # молча (result=skipped), когда build падает (например, битый blob в # buildcache роняет `docker/build-push-action` — до ретрая выше, #2841). # skipped-job НЕ красит прогон явным «FAILED» так, чтобы это было видно на # первый взгляд — итог выглядит зелёным/нейтральным, хотя прод не обновился. # Эта job бежит ВСЕГДА (`if: always()`, кроме отмены прогона) и сама падает, # если deploy не завершился success — неважно, пропущен он (build упал) или # упал сам (SSH/миграция/health-check). Красная точка встаёт именно там, где # решение реально принято, а не там, где она случайно оказалась по цепочке if. # ── Быстрый путь: правка ТОЛЬКО конфига прокси (#2916) ──────────────────── # # ЗАЧЕМ. `Caddyfile` лежит в фильтре `infra`, поэтому правка одной строки # allowlist'а ради meraocenka.ru запускала полный деплой Site Finder: # пересборку трёх образов, `git reset --hard` на боевой VM, применение ВСЕХ # pending `data/sql/*.sql` в боевой БД gendsgn и `--force-recreate` бэкенда, # воркера, beat и caddy. То есть радиус поражения правки, относящейся к # чужому домену, — gendsgn.ru целиком, включая миграции продукта, который # никто в этот момент катить не собирался. # # Публичный периметр МЕРЫ живёт в этом файле и будет меняться часто: новая # страница = новая строка allowlist'а. # # ПОЧЕМУ `reload`, А НЕ `up -d --force-recreate caddy`. Полный деплой # осознанно пересоздаёт контейнер (комментарий в ci.yml: `reload` отказался бы # принять битый конфиг и оставил бы работать старый — на общем деплое это # скрыло бы поломку). Здесь наоборот: правится ТОЛЬКО конфиг, и отказ # применить битый — ровно то, что нужно. `caddy reload` возвращает ненулевой # код → job краснеет, а домены продолжают обслуживаться старым конфигом. # Альтернатива (`--force-recreate`) на опечатке уводит контейнер в crash-loop # и роняет ВСЕ домены сразу. # # Гейт `caddy validate` на PR (#2913) остаётся первой линией; этот шаг — # вторая, уже против боевого файла после `git reset`. deploy-caddy: runs-on: ubuntu-latest needs: changes # Только push: на workflow_dispatch человек просит полный деплой, и # подменять его перезагрузкой конфига нельзя. if: github.event_name == 'push' && needs.changes.outputs.caddy_only == 'true' steps: - name: Синхронизировать конфиг и перезагрузить прокси uses: appleboy/ssh-action@v1.0.3 with: host: ${{ secrets.DEPLOY_HOST }} username: ${{ secrets.DEPLOY_USER }} key: ${{ secrets.DEPLOY_SSH_KEY }} port: ${{ secrets.DEPLOY_PORT }} script: | set -euo pipefail cd /opt/gendesign git fetch origin main git reset --hard origin/main # Конфиг примонтирован read-only с хоста, пересборка не нужна — # контейнер читает тот же файл, что только что обновил git. docker compose -p gendesign -f docker-compose.prod.yml exec -T caddy \ caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile echo "✓ конфиг прокси перезагружен без пересборки и без миграций" # ── Смоук публичного периметра МЕРЫ после выкатки (#2917) ────────────────── # # ЗАЧЕМ ЗДЕСЬ. scripts/smoke-mera-perimeter.sh — единственная проверка, которая # видит периметр целиком (короткие адреса, 301 с длинных, публичный API, # закрытость B2B-путей на публичном домене). До этого PR он запускался только # по cron'у 06:17 UTC, то есть регресс жил до суток и находил его либо ночной # прогон, либо владелец. Для правки, чья логика живёт в конфиге прокси, это # единственный настоящий гейт — и он был асинхронным. # # ПОЧЕМУ ОТДЕЛЬНЫЙ JOB, А НЕ ШАГ В deploy. Вердикты разные: «выкатили» и # «периметр цел» — два разных факта, и красный смоук не должен читаться как # неудавшийся деплой. Деплой к этому моменту уже прошёл; смоук говорит, что # именно получилось. # # ПОЧЕМУ ДУБЛИРУЕТСЯ В ДВУХ ПАЙПЛАЙНАХ. Конфиг прокси (deploy.yml) и фронт # МЕРЫ (deploy-tradein.yml) едут раздельно, и сломать периметр может каждый. # `workflow_call` под act_runner не гарантирован, поэтому 20 строк повторены # осознанно вместо зависимости, которая может молча не сработать. perimeter-smoke: runs-on: ubuntu-latest needs: [deploy, deploy-caddy] # Только после РЕАЛЬНОЙ выкатки: при skipped/failed проверять нечего, а # красный смоук поверх несостоявшегося деплоя увёл бы разбор не туда. # ЛЮБОЙ из двух путей (#2916): быстрый путь трогает как раз конфиг прокси, # то есть ровно то, что смоук и проверяет — пропустить его там было бы # хуже всего. if: | always() && (needs.deploy.result == 'success' || needs.deploy-caddy.result == 'success') timeout-minutes: 6 steps: - uses: actions/checkout@v4 - name: Дождаться, пока периметр отвечает после пересоздания контейнеров # `up -d --force-recreate` возвращает управление раньше, чем бэкенд # начинает отвечать. Без ожидания смоук ловил бы не регресс, а гонку. # Ждём ДВА признака: лэндинг (Caddy + фронт) и API (бэкенд поднялся) — # одного мало, Caddy отвечает раньше апстрима. run: | set -uo pipefail for i in $(seq 1 30); do page=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 https://meraocenka.ru/ || true) api=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 https://gendsgn.ru/trade-in/api/v1/me || true) if [ "$page" = "200" ] && [ "$api" = "401" ]; then echo "периметр отвечает (попытка $i): лэндинг $page, API $api" exit 0 fi echo "ждём готовности, попытка $i/30: лэндинг '${page:-нет ответа}', API '${api:-нет ответа}'" sleep 5 done # НЕ падаем здесь: вердикт должен вынести смоук, а не таймаут ожидания. # Иначе «не успел подняться» и «периметр сломан» слились бы в один # красный шаг без разбора. echo "::warning::за 150 с периметр так и не ответил ожидаемо — запускаем смоук, его вывод и будет диагнозом" - name: Смоук периметра run: | chmod +x scripts/smoke-mera-perimeter.sh ./scripts/smoke-mera-perimeter.sh deploy-status: runs-on: ubuntu-latest needs: [build-backend, build-worker, build-frontend, deploy, deploy-caddy] if: always() && !cancelled() steps: - name: Итог прогона — выкатка обязана быть success, не skipped/failure # #2916: путей выкатки теперь ДВА — полный деплой и быстрая перезагрузка # конфига прокси. Успешен прогон, если сработал ЛЮБОЙ из них; ошибка — # когда не сработал ни один. Требовать `deploy == success` как раньше # значило бы красить каждую правку прокси, которая как раз прошла. run: | echo "build-backend: ${{ needs.build-backend.result }}" echo "build-worker: ${{ needs.build-worker.result }}" echo "build-frontend: ${{ needs.build-frontend.result }}" echo "deploy: ${{ needs.deploy.result }}" echo "deploy-caddy: ${{ needs.deploy-caddy.result }}" if [ "${{ needs.deploy.result }}" = "success" ]; then echo "✓ полный деплой прошёл успешно" elif [ "${{ needs.deploy-caddy.result }}" = "success" ]; then echo "✓ конфиг прокси перезагружен (быстрый путь, без пересборки и миграций)" else echo "::error::выкатка НЕ прошла ни одним путём" \ "(deploy=${{ needs.deploy.result }}," \ "deploy-caddy=${{ needs.deploy-caddy.result }})." \ "Прогон должен читаться как FAILED, а не как пропущенный шаг (#2841)." \ "Смотри логи build-* / deploy / deploy-caddy выше." exit 1 fi