.forgejo/workflows/ci.yml

@@ -15,23 +15,22 @@ name: CI
 # FUTURE: добавить `postgis/postgis:16-3.4` service + гонять mv_layout — см.
 # .github/workflows/ci.yml как образец service-блока.
 on:
+  # ТОЛЬКО pull_request — НЕТ push-триггера на feature-ветки (CI-шторм #1709).
+  # WHY: раньше был и push: [feat/**,fix/**,...]. Каждый коммит в ветку с открытым
+  # PR триггерил ДВА прогона на ОДИН SHA: push-событие (github.ref=refs/heads/<branch>)
+  # и pull_request-событие (github.ref=refs/pull/<N>/merge). Разный github.ref →
+  # разные concurrency-группы (см. ниже) → прогоны НЕ отменяют друг друга → 2× job
+  # при и так дефицитных раннерах. В bot-пайплайне каждый коммит идёт через PR, так
+  # что pull_request гейтит его полностью; push-прогон был чистым дублем.
+  # Trade-off: push в feature-ветку БЕЗ открытого PR не получит CI до открытия PR
+  # (бот открывает PR сразу после первого push) — приемлемо.
   pull_request:
     branches: [main]
-  push:
-    branches:
-      # Mirror the bot-PR / feature-branch flow в .claude/rules/git-pr.md:
-      # PR получает gate, прямые пуши в feature-ветки — тоже.
-      - "feat/**"
-      - "fix/**"
-      - "refactor/**"
-      - "chore/**"
-      - "docs/**"
-      - "perf/**"
-      - "test/**"
-      - "ci/**"
-      - "hotfix/**"
 
 concurrency:
+  # Теперь, когда остался только pull_request, github.ref стабилен на весь PR
+  # (refs/pull/<N>/merge) → новый push в ветку PR отменяет предыдущий незавершённый
+  # прогон ЭТОГО PR (cancel-in-progress) вместо накопления параллельных.
   group: ci-${{ github.workflow }}-${{ github.ref }}
   cancel-in-progress: true