recipe-maintainers/cc-ci-orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(launch): forward PHASES_SPEC/backend to watchdog; mark plan Phase 4 as operator gate

Browse Source 
The watchdog is spawned into the existing tmux server and didn't reliably
inherit a custom PHASES_SPEC — it would fall back to the default 11-phase
spec and mis-detect completion. Forward PHASES_SPEC/PHASE_IDX_FILE/
LOOP_BACKEND/LOOP_MODEL explicitly in the watchdog command so custom
single-phase runs (like the mirror-enroll plan) work end-to-end. Also make
the mirror-enroll plan's live-host-deploy step an explicit claim-and-wait
operator gate for the loops.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
autonomic-bot
2026-06-02 00:15:42 +00:00
parent 8007053d94
commit d349656c3b
2 changed files with 14 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
cc-ci-plan/launch.py
View File

@ -610,9 +610,16 @@ def start_watchdog():
return
log("starting watchdog")
script = Path(__file__).resolve()
# Forward the phase spec / idx file / backend explicitly. The watchdog tmux session is spawned
# into the existing tmux server and would otherwise NOT inherit a custom PHASES_SPEC from the
# caller's env — it would fall back to the default spec and mis-detect phase completion.
env_prefix = (
f"PHASES_SPEC='{PHASES_SPEC}' PHASE_IDX_FILE='{PHASE_IDX_FILE}' "
f"LOOP_BACKEND='{BACKEND}' LOOP_MODEL='{LOOP_MODEL}' "
)
subprocess.run([
"tmux", "new-session", "-d", "-s", WATCHDOG_SESSION, "-c", PLAN_DIR,
f"exec >>'{LOG_DIR}/watchdog.log' 2>&1; python3 '{script}' watchdog"
f"exec >>'{LOG_DIR}/watchdog.log' 2>&1; {env_prefix}python3 '{script}' watchdog"
])
# ── preflight ─────────────────────────────────────────────────────────────────

9
cc-ci-plan/plan-mirror-enroll-all-recipes.md
View File

@ -59,9 +59,12 @@ do). Commit to the cc-ci product repo. Final `POLL_REPOS` = cc-ci + all 19 recip
### Phase 4 — deploy to the live cc-ci host ⚠️ OPERATOR GO-AHEAD GATE
`cd /root/cc-ci && nixos-rebuild switch --flake .#cc-ci` on the cc-ci host (or the repo's deploy path).
Restarts the bridge with the new poll set. **This is the one high-impact step** (live CI server); do
not run without explicit go-ahead. Note: `/root/cc-ci` on the host is an operator-synced copy — confirm
it's at the committed head first (this was a noted gap: no self-service host rebuild path).
Restarts the bridge with the new poll set. **This is the one high-impact step** (live CI server).
**LOOPS: do NOT run this yourselves.** CLAIM this gate in STATUS — state the exact command, that
`/root/cc-ci` is at the committed head, and that Phases 1-3 are Adversary-verified — then WAIT for the
operator to perform/approve the rebuild. (Footgun is mitigated now that `#cc-ci` → the Hetzner host
config via `be4f451`, but the live-host rebuild stays an operator action.) Note: `/root/cc-ci` is an
operator-synced copy — there is no self-service host rebuild path (a known gap).
### Phase 5 — verify `!testme` triggerability
For 2-3 newly-enrolled recipes, post `!testme` on an open PR (or a scratch PR) and confirm a Drone