64 lines
4.5 KiB
Markdown
64 lines
4.5 KiB
Markdown
# 07 — Инфра-требования: ORCH-089 (авто-режим по лейблам)
|
||
|
||
## I-1. Создать лейблы в Plane-проекте ORCH (однократно, обязательно)
|
||
|
||
Авто-режим управляется лейблами на задаче. В Plane-проекте ORCH сейчас лейблов
|
||
`autoApprove`/`autoDeploy` **нет** — их нужно создать один раз через labels API:
|
||
|
||
```
|
||
POST {PLANE_BASE}/workspaces/{WORKSPACE}/projects/{ORCH_PROJECT_ID}/labels/
|
||
Headers: PLANE_HEADERS
|
||
Body: {"name": "autoApprove"}
|
||
|
||
POST {PLANE_BASE}/workspaces/{WORKSPACE}/projects/{ORCH_PROJECT_ID}/labels/
|
||
Body: {"name": "autoDeploy"}
|
||
```
|
||
|
||
Имена должны **точно** соответствовать `auto_approve_label` / `auto_deploy_label`
|
||
(дефолты `autoApprove` / `autoDeploy`). Сопоставление в коде — по нормализованному имени
|
||
(`strip().casefold()`), т.е. регистр/пробелы не критичны, но рекомендуется создать ровно
|
||
как в дефолте.
|
||
|
||
**Fail-safe при отсутствии:** если лейбл в проекте не создан, `labels.has_label` всегда
|
||
вернёт `False` → задача идёт ручным путём (нулевой риск, без ошибок). То есть создание
|
||
лейблов — предусловие активации фичи, а не условие стабильности конвейера.
|
||
|
||
## I-2. Сброс кэша состояний/лейблов после создания (рекомендуется)
|
||
|
||
`get_project_labels` кэширует карту лейблов проекта с TTL `auto_label_states_ttl_s`
|
||
(дефолт 300с). После создания новых лейблов карта подтянется автоматически в течение TTL;
|
||
для немедленного эффекта — рестарт не требуется, достаточно дождаться TTL или (если будет
|
||
добавлен) вызвать reload-хелпер кэша лейблов по образцу `reload_project_states`.
|
||
|
||
## I-3. Конфигурация (env, хост mva154)
|
||
|
||
По умолчанию фича включена (`auto_label_enabled=True`) и применима только к self-hosting
|
||
репо (`auto_label_repos=""` → `orchestrator`). Управляющие env (опционально, в `.env`):
|
||
|
||
| Env | Дефолт | Эффект |
|
||
|-----|--------|--------|
|
||
| `ORCH_AUTO_LABEL_ENABLED` | `true` | Глобальный kill-switch. `false` → оба гейта ручные, нулевой сетевой оверхед. |
|
||
| `ORCH_AUTO_APPROVE_LABEL` | `autoApprove` | Имя лейбла гейта BRD. |
|
||
| `ORCH_AUTO_DEPLOY_LABEL` | `autoDeploy` | Имя лейбла гейта деплоя. |
|
||
| `ORCH_AUTO_LABEL_REPOS` | `` (пусто) | CSV scope. Пусто → self-hosting only. |
|
||
| `ORCH_AUTO_LABEL_STATES_TTL_S` | `300` | TTL кэша карты лейблов проекта. |
|
||
|
||
## I-4. Сетевые/доступ
|
||
|
||
Новых endpoint оркестратора нет. Дополнительные **исходящие** вызовы к Plane API v1
|
||
(те же креды `PLANE_HEADERS`, таймаут 10с):
|
||
- `GET …/issues/{issue_id}/` (поле `labels`) — чтение лейблов задачи на гейте;
|
||
- `GET …/projects/{pid}/labels/` — карта лейблов проекта (кэш с TTL);
|
||
- `PATCH …/issues/{issue_id}/` `{"state": <approved_uuid>}` — индикация авто-аппрува.
|
||
|
||
Вызовы — только когда `applies(repo)==True` (kill-switch off / репо вне scope → нет
|
||
вызовов). Недоступность Plane → fail-safe к ручному гейту (конвейер не блокируется).
|
||
|
||
## I-5. Топология / прод-риск
|
||
|
||
Self-hosting не меняется: autoDeploy лишь авто-инициирует **существующий** Phase B
|
||
(detached host-деплой через `scripts/orchestrator-deploy-hook.sh`). Никакого нового пути
|
||
рестарта прод-контейнера не вводится. Phase C / merge-verify / regression-guard /
|
||
post-deploy monitor продолжают верифицировать результат. Раскат — под kill-switch
|
||
(`ORCH_AUTO_LABEL_ENABLED`), деплой self — через обязательный staging-гейт (8501), как всегда.
|