Files
cc-ci-orchestrator/cc-ci-plan/plan-phase-drone-enroll.md
autonomic-bot 327b9f4efe plan: phases dstamp, mailu, kuma, drone (queued after bsky) + journal
- dstamp: attribute + fix the discourse abra-stamp drift (env change 06-05→
  06-10, harness-neutral, currently pinning discourse at L1); blast-radius
  sweep; HC1 keeps its teeth
- mailu: backupbot v2 labels recipe PR, restore proven on real seeded mail,
  backup rung earned instead of skipped (operator approved re-entry)
- kuma: uptime-kuma first-run wizard + create-a-monitor functional test
  (Socket.IO or Playwright, real probe evidence, flake-checked)
- drone: gitea-dep enrollment, maximal subset per Phase-2 scoping;
  P0 /etc/timezone host deploy is orchestrator-owned (3bde76f committed)
2026-06-11 11:43:03 +00:00

86 lines
5.1 KiB
Markdown

# Phase `drone` — enroll the drone recipe (with gitea SCM dependency)
**Mission (operator-specified 2026-06-11):** enroll drone — the last §5 recipe — in
cc-ci. Drone is a CI server that requires a git-provider SCM to boot; the viable dep is
gitea. Ship the MAXIMAL SUBSET scoped in Phase 2 (JOURNAL-2 `f86a58a`): drone boots with
gitea SCM — install + upgrade + health + SCM-configured — with the build-creation test
remaining a signed-off sub-deferral.
State files: `STATUS-drone.md`, `BACKLOG-drone.md`, `REVIEW-drone.md`,
`JOURNAL-drone.md`. DECISIONS.md shared.
## 0. P0 — HOST PREREQUISITE (orchestrator-owned; verify before any other work)
gitea binds `/etc/timezone:ro` from the host; NixOS `time.timeZone` creates only
`/etc/localtime`, so the gitea container is REJECTED (`bind source path does not exist`)
— proven on cc-ci. The Nix fix is ALREADY COMMITTED: `3bde76f`
(`environment.etc."timezone" = "UTC\n"` in `nix/hosts/cc-ci/configuration.nix`); it
needs the host-config deploy (sync `/root/cc-ci` + `nixos-rebuild switch
--flake /root/cc-ci#cc-ci`), which the ORCHESTRATOR performs (operator-managed
mechanism; do NOT attempt it from the loops).
**Builder's first action:** check `test -f /etc/timezone` on the cc-ci host. If absent,
write a BLOCKED note at the top of STATUS-drone.md ("P0 host deploy needed —
orchestrator") and work on P1 prep that needs no gitea deploy (meta scaffolding, test
authoring) until it appears; the orchestrator reads STATUS on its hourly wakes and will
deploy. Verify `/etc/timezone` exists (content `UTC`) before claiming anything gitea
touches.
## 1. Scope (from the Phase-2 scoping, JOURNAL-2 `f86a58a`)
1. **gitea as a dependency recipe:** `tests/gitea/recipe_meta.py` enrolling gitea as an
install-time DEPS provider (per the rcust install-time-deps-only system — deps are
installed before the app, fixtures `deps`/`op_state` provide handles).
2. **drone enrollment:** `tests/drone/recipe_meta.py` with `DEPS=["gitea"]`;
install-time steps that create a gitea admin + token + OAuth2 application and wire
`DRONE_GITEA_*` + client secret into drone's install; functional tests proving
health + **SCM-configured** (drone actually talks to gitea, not just an HTTP 200).
3. **Tiers:** install + upgrade (if a previous published version exists — justify
either way) + functional; backup/restore per what the published recipe declares
(structural skip is fine if the recipe has no backup config — document it); lint
(L5) per the now-standard ladder. Screenshot per the shot-phase standard (drone has
a real login/landing UI; default capture expected to work).
4. **Build-creation sub-deferral STAYS deferred:** creating/listing actual CI builds
needs an OAuth user-token + synced repo + .drone.yml + webhook trigger —
disproportionate (the original Phase-2 assessment stands). Ship without it and get
the Adversary's explicit §7.1-style sign-off recorded in REVIEW-drone.md; update
the DEFERRED entry to narrow it to just this gap.
## 2. Gates
**M1 — Integration built + green locally.** P0 verified; gitea dep + drone enrollment
implemented; full chosen tier-set green on the harness path with evidence; unit tests
for any new harness-visible surface; no gate weakening anywhere. Adversary cold-verifies
from a clean checkout: deps wiring per the rcust conventions, SCM-configured test has
teeth (a drone WITHOUT gitea wiring must fail it), declared skips justified against the
published recipe.
**M2 — Proven in real CI.** Full lifecycle green via the drone `!testme`/CI path
(yes — cc-ci's own drone testing a drone recipe deploy; mind resource headroom),
screenshot real + visually verified, level recorded under the de-capped semantics,
canonical/warm enrollment decision documented, DEFERRED entry updated (P0+integration
closed, build-creation gap narrowed + signed off), operator summary in STATUS-drone.md.
Fresh Adversary PASS → `## DONE`.
## 3. Guardrails (binding)
- **Host changes are orchestrator/operator-only** (P0 above; same for anything else
host-level you discover — file it in STATUS, don't improvise).
- The deps system rules from rcust apply: install-time deps only, uniform HookCtx
signatures, no new meta keys without registry + docs regeneration.
- Two live deploys (gitea + drone) per run — count them against the ≤2-3 concurrent
budget; coordinate so a second recipe's run isn't racing the same headroom; tear down
BOTH on every exit path, dep included.
- Recipe mirrors: PR only if a recipe defect is found (never push main, never merge).
No secrets in logs/commits (gitea admin password + OAuth client secret are generated
per-run and must stay out of artifacts; the manifest redaction rules apply).
- Commit author `autonomic-bot <autonomic-bot@noreply.git.autonomic.zone>`; push every
commit. CI host: no python3 on default PATH.
## 4. Definition of Done
`/etc/timezone` host fix live; gitea enrolled as a dep provider; drone enrolled and
green (install/upgrade/health/SCM-configured + lint + screenshot) through real CI with
the build-creation gap explicitly signed off and DEFERRED narrowed; levels + records
reconciled; M1+M2 fresh Adversary PASSes.