4.5 KiB
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), как всегда.