2.5 KiB
2.5 KiB
07 — Требования к инфраструктуре (ORCH-043)
Вывод: топология не меняется. Новых контейнеров/портов/сервисов нет.
| Аспект | Требование |
|---|---|
| Контейнеры | Без изменений. Прод orchestrator (8500) и orchestrator-staging (8501) — как есть. |
| Порты | Без изменений. |
| Сеть/внешние сервисы | Без новых зависимостей. Используются существующие git/Gitea (fetch/push) и pytest. |
| Файловая система | Новый артефакт времени выполнения — lease-файл <repos_dir>/.merge-lease-<repo>.json (см. 08-data-requirements.md). Лежит в уже примонтированном repos_dir (/repos). Дополнительного volume не требуется. |
| Worktree | Переиспользуется существующая изоляция (/repos/_wt/<repo>/<branch>, ORCH-2). Все git-операции merge-gate — в worktree. |
.env / compose / прод-инфра |
НЕ изменяются (AC-14). Новые ORCH_* настройки имеют безопасные дефолты (см. ADR-001 §6) и документируются в .env.example. |
Эксплуатационные требования
- git push прав для оркестратора достаточно существующих (он уже пушит ветки/PR-артефакты).
Merge-gate пушит ТОЛЬКО ветку задачи (
--force-with-lease),main— никогда. - Раскат поэтапно:
merge_gate_enabled=Falseили пустойmerge_gate_repos(реален только дляorchestrator) позволяют включать гейт постепенно без риска для чужих репо. - Self-hosting-страховка сохранена: изменения ORCH-043 проходят обязательную стадию
deploy-staging(8501) до прод-деплоя самого оркестратора; прод-контейнер не рестартится в рамках задачи.
Рекомендация по процессу
Изменение сквозное (новый QG + поведение ребра deploy-staging → deploy) →
рекомендуется лейбл arch:major-change. Прод-деплой ORCH-043 — строго через staging-гейт.