45 lines
3.3 KiB
Markdown
45 lines
3.3 KiB
Markdown
# 07 — Требования к инфраструктуре: ORCH-059
|
||
|
||
Work Item: **ORCH-059** · Repo: `orchestrator`
|
||
Связано: `06-adr/ADR-001-confirm-deploy-status.md`, `02-trz.md` §6.
|
||
|
||
> Топология контейнеров/портов/деплоя НЕ меняется (см. `docs/operations/INFRA.md`).
|
||
> Единственное инфра-требование ORCH-059 — конфигурация Plane-доски проекта ORCH.
|
||
|
||
## IR-1. Статус доски «Confirm Deploy» в проекте ORCH (предусловие эксплуатации)
|
||
- В Plane-проекте **ORCH** создать кастомный статус доски с **точным** именем
|
||
`Confirm Deploy` (case-sensitive, ровно один пробел) — должно посимвольно
|
||
совпасть с ключом `_PLANE_NAME_TO_KEY["Confirm Deploy"]`. Несовпадение →
|
||
fail-closed (деплой не запустится), не краш (R-9).
|
||
- UUID статуса генерирует Plane; код резолвит его через `get_project_states`
|
||
(`GET /workspaces/<ws>/projects/<orch>/states/`). Хардкодить UUID не нужно.
|
||
- **Размещение** на доске — рядом с approval-pending/`deploy` (рекомендация
|
||
эксплуатации, на поведение кода не влияет).
|
||
- **Только проект ORCH** (self-hosting). Для enduro и прочих проектов статус НЕ
|
||
создаётся и НЕ требуется — `self_deploy_applies` истинно лишь для `orchestrator`.
|
||
|
||
## IR-2. Сброс кэша состояний после создания статуса
|
||
`get_project_states` кэширует резолв per-project на время жизни процесса
|
||
(`_STATES_CACHE`). После создания статуса в Plane закэшированный словарь не
|
||
содержит `confirm_deploy` (R-5). Применить ОДНО из:
|
||
- вызвать `reload_project_states(<orch_project_id>)` (или полный сброс), либо
|
||
- штатно перезапустить прод по конвейеру `deploy-staging → deploy` (рестарт
|
||
процесса очищает кэш).
|
||
|
||
> Внеплановый ручной рестарт прод-контейнера для применения этой задачи **не
|
||
> требуется** и противопоказан (self-hosting групповой риск). Выкат — только через
|
||
> штатный staging→deploy.
|
||
|
||
## IR-3. Контрольная проверка готовности среды
|
||
После IR-1+IR-2:
|
||
1. `get_project_states(<orch>)` содержит `confirm_deploy` с непустым UUID,
|
||
отличным от `approved` (AC-1, TC-02).
|
||
2. Перевод тестовой задачи стадии `deploy` (sandbox) в `Confirm Deploy` запускает
|
||
Фазу B; перевод в `Approved` — нет (AC-2/AC-3).
|
||
|
||
## Что НЕ меняется
|
||
- Порты (8500 prod / 8501 staging), контейнеры, compose-профили, env-карта,
|
||
деплой-хук, схема БД, sentinel-каталоги ORCH-036 — без изменений.
|
||
- HTTP-эндпоинты (`POST /webhook/plane` тот же канал, событие
|
||
`work_item.updated`).
|