auto-sync: 2026-06-04 22:30:01

This commit is contained in:
Stream
2026-06-04 22:30:01 +03:00
parent 5b2b80b38e
commit f38f730435

View File

@@ -1,20 +1,11 @@
### ✅→⚠️ PR #26 (CI-workflow orchestrator) — создан, но CI КРАСНЫЙ (требует решения)
- Dev (tokenator/claude-sonnet-4-6) сделал ровно один файл `.gitea/workflows/ci.yml` (22 строки, как в ТЗ), ветка `ci/add-gitea-workflow`, коммит `b6d6b53`, **PR #26**. Diff = 1 файл, чисто.
- Workflow реально прогнался (Gitea Actions, run 541/542) → **conclusion: failure** (3 failed / 291 passed).
- **Я проверила причину на проде (docker run, read-only volume, без .env — как в CI):** падают `test_plane_webhook_creates_task`, `test_gitea_push_with_adr_advances_stage` (+ ci_failure тест).
- **Корень = PRE-EXISTING дефект изоляции тестов, НЕ вина PR.** Тесты лезут к живому Plane API (`plane_sync` → Connection refused в чистом окружении) → webhook-цепочка обрывается до создания задачи / до `launch`. Замокано только `_create_gitea_branch` и `_create_initial_docs`, а вызов Plane — нет.
- На хосте локально они «проходят» лишь потому что там живой Plane/сеть. CI впервые честно вскрыл хрупкость.
- **Вывод:** workflow-файл КОРРЕКТЕН. Чтобы CI стал зелёным — надо ОТДЕЛЬНОЙ задачей замокать Plane API в этих 3 тестах (дефект изоляции). Либо временно исключить их из CI (xfail/skip с пометкой) — но честнее починить моки.
### ⚠️ РАННЕР-БАРДАК на хосте (Dev наплодил, нужна уборка — решение Славы)
Сейчас **3 процесса act_runner** (инвентаризация, я НЕ убивала ничего):
1. PID 3828601 — `--config config.yaml` (cwd /home/slin), .runner `mva154-runner` labels [self-hosted:host]. Старый, с 19.05.
2. PID 3829071 — `--config /home/slin/act_runner_data/config.yaml`, .runner `mva154-runner` labels [ubuntu-latest..., self-hosted:host]. **Это systemd `act-runner.service`** (ExecStart=…act_runner_data/config.yaml, WorkingDirectory=act_runner_data). Основной, рабочий.
3. PID 4091018 — `--config config.yaml`, cwd `/home/slin/act_runner_orch`, .runner `mva154-runner-orch`. **Запущен Dev'ом через nohup сегодня 21:14 — НЕ переживёт reboot, не systemd.**
- Раннер #1 (3828601) — похоже легаси-дубль, тоже не под systemd.
- **TODO для Славы:** (а) решить нужен ли отдельный orch-раннер вообще (он global-scope, label self-hosted:host — тот же что enduro; возможно ОДНОГО systemd-раннера достаточно для обоих репо, надо проверить scope регистрации); (б) если нужен — оформить systemd unit, не nohup; (в) прибить лишние процессы 3828601 и/или 4091018. НЕ трогала сама — это инфра-изменение, требует ОК.
### 🎯 Статус задачи №1
- Файл CI готов и корректен, НО merge PR #26 ПРЕЖДЕВРЕМЕНЕН: смержить зелёный workflow, который сразу красит main красным из-за pre-existing тестов — плохо. Сначала почистить либо тесты (моки Plane), либо явно skip'нуть 3 теста в CI с задачей-фоллоуапом.
- Раннер привести в порядок (systemd unit вместо nohup) до того как полагаться на CI для self-hosting.
### 📋 ORCH-30 создана: тестовые среды (test/staging) для конвейера
- Слава голосом: где происходит тестирование? Нужна тестовая среда (не dev/не prod) для прогона функционала тестером «как будто прод». Для orchestrator И для enduro-trails. Просил записать анализ в задачу Plane.
- **Проверила на проде — Слава ПРАВ, тестовых сред НЕТ:**
- enduro-trails: 1 контейнер `enduro-trails-app-1` (5556), деплой = `enduro-deploy-hook.sh` (git pull + compose up на тот же контейнер) → сразу PROD.
- orchestrator: 1 контейнер, деплой-хука вообще нет.
- Тестируется только CI (pytest на push) — это юнит-тесты в чистом job, НЕ живой функционал. Стадия `testing` есть, но тестеру прогонять не на чем.
- Деплой = первый запуск нового кода сразу в прод. Для self-hosting orchestrator опасно вдвойне (оркестратор кладёт сам себя).
- **Записала в ORCH-30** (id `85da2b10-6dc4-4693-b611-e96c6117f565`, seq 30, Backlog): анализ + 3 варианта (A эфемерный CI-стенд / B постоянный staging / C гибрид — рекомендую) + правки методики (стадия deploy-staging ПЕРЕД deploy-prod, тестер на staging-эндпоинт, build-once-promote, seed-фикстуры) + 5 открытых вопросов Славе. Связь: блокирует ORCH-7, пересекается с ORCH-21.
- **Грабли Plane API (запомнить):** env `ORCH_PLANE_API_URL=http://localhost:8091` БЕЗ `/api/v1` — суффикс добавляет код (`plane_sync.py:15 PLANE_BASE=f"{url}/api/v1"`). Если дёргать API вручную — добавлять `/api/v1` самой, иначе Plane вернёт HTML (200) вместо JSON. Заголовок `X-API-Key`. Скрипт лить в контейнер orchestrator через base64-stdin+docker cp (scp на воркстейшене НЕТ, прямого доступа к localhost:8091 из контейнера ассистента НЕТ).
- enduro-deploy-hook УЖЕ умеет rollback (PREV_IMG) — пригодится для ORCH-21/staging.