cc-ci/STATUS.md

STATUS — cc-ci Builder

Phase: M6 complete & CLAIMED. M0/M1/M2/M4/M5 PASS. M3 gate BLOCKED (Gitea webhook; operator). Next: M6.5 (breadth ramp — recipes 3–6 + keycloak full 3-stage), M7, M8. Resolve M3 trigger before M10. In-flight: M6.5 — keycloak full 3-stage (DB survival), then enroll recipes covering remaining categories. Last updated: 2026-05-27 (M6 claimed; D4 + recipe #2)

Gates

• Gate: M0 — CLAIMED, awaiting Adversary (2026-05-26). Evidence: flake rebuilds cc-ci from repo (switch --flake /root/cc-ci#cc-ci, gen healthy, no failed units); sops-nix decrypts /run/secrets/test_secret (0400 root, value = generated cc-ci-m0-…). Repro: clone repo, sync to host, nixos-rebuild switch --flake .#cc-ci, then systemctl is-system-running + check the secret. Per §6.1 I will NOT advance past this gate to M2; M1 work proceeds as independent unblocked work. → M0 PASS logged by Adversary in REVIEW.md @2026-05-26T21:35Z (cold verify, leak probe clean).
• Gate: M1 — CLAIMED, awaiting Adversary (2026-05-26). Evidence: Docker single-node swarm + proxy overlay; real coop-cloud/traefik via abra (wildcard/file-provider, no ACME); custom-html deployed by hand → HTTP 200 over HTTPS via gateway at cchtml1.ci.commoninternet.net with the wildcard cert; torn down clean (services/volumes/secrets/containers all 0). Repro: scripts/deploy-proxy.sh + abra app new/deploy/undeploy. Starting M2 as independent work; will not flip M2's gate until M1 shows PASS. → M1 PASS @2026-05-26T22:20Z.
• Gate: M2 — CLAIMED, awaiting Adversary (2026-05-26). Evidence: Drone server (coop-cloud recipe, reconcile oneshot, Gitea SSO) healthz 200 via gateway; exec runner polling (capacity=2). cc-ci repo activated (push webhook). Pushing .drone.yml triggered build #1 → success (clone + hello exec steps, exit 0; ran abra/docker on the host). Repro: nixos-rebuild switch + one-time scripts/bootstrap-drone-oauth.sh. Starting M3 as independent work; won't flip M3 gate until M2 PASS.

Blocked

• M3 gate — Gitea→bridge webhook delivery (operator FIXING: whitelisting ci.commoninternet.net in git.autonomic.zone ALLOWED_HOST_LIST). Orchestrator update 2026-05-27: keep the webhook design, do NOT pivot to polling. Bridge + webhook (id 210) left in place as-is (webhook-only; the brief polling experiment was reverted). When the operator pings that the whitelist is applied: re-test delivery (Gitea Test Delivery or re-comment !testme on PR #1), confirm the bridge gets the POST + triggers a Drone build, then claim the M3 gate. Working other milestones meanwhile. Original diagnosis below for reference. The comment-bridge is built, deployed (swarm service behind traefik), and publicly reachable: https://ci.commoninternet.net/hook/healthz → 200 from the sandbox over real public DNS (ci.commoninternet.net → gateway 143.244.213.108). HMAC logic verified (a manually openssl-signed POST is accepted; bad sig → 401). BUT Gitea never delivers: commenting !testme on PR #1 and even Gitea's "Test Delivery" (UI returns 200/queued) produce zero requests at the bridge container (and traefik accessLog is off, so unobservable there). Bridge is reachable from a 3rd network, gateway accepts public sources, public DNS is correct → Gitea is not sending the HTTP request. Most likely git.autonomic.zone's [webhook] ALLOWED_HOST_LIST excludes ci.commoninternet.net (bot is not Gitea admin, can't inspect/change). Operator options: (a) add ci.commoninternet.net to Gitea's webhook allowed-host list; or (b) tell me to pivot the bridge to poll the Gitea API for !testme comments (self-service, satisfies D1's 60s; recorded as the fallback). Not globally blocking — M4 (harness + install stage) is independent of the trigger path (dev builds triggerable via the Drone API), so I proceed there meanwhile.

Tracking (adversary findings I must address)

• [adversary] A1 — no-ACME hazard for test apps. Acknowledged (valid). The harness (M4) MUST force LETS_ENCRYPT_ENV="" on every test-app deploy (already done in scripts/deploy-proxy.sh and the M1 manual custom-html deploy; scripts/deploy-drone.sh will too). Considering a structural belt-and-suspenders (drop the unused certificatesResolvers from cc-ci's traefik) — deferred, needs a recipe-config override. Will make the harness enforcement the primary fix; Adversary re-tests + closes after M4. → Now enforced: harness.lifecycle.deploy_app sets LETS_ENCRYPT_ENV="" on every test-app deploy (verified in the M4 custom-html run). Adversary can re-test + close A1.

Notes

• Disk RESOLVED: operator grew the VM 8.9→28 GiB (22 GiB free) on 2026-05-26. Inodes 1.78M total / 1.21M free (was ~6k free — old 8.9 GiB fs had only 586k inodes, which the flake's nixpkgs fetch exhausted). Both byte + inode pressure gone.
• M0 base config: flake at repo root pins nixpkgs to the exact rev cc-ci ran (50ab793) → first rebuild is no-op-then-base. Deployed via nixos-rebuild switch --flake /root/cc-ci#cc-ci run as a detached transient systemd unit (survives ssh-over-tailscale drops). Gen 3 current, healthy.
• Open warning: incus module enables systemd.network while we set networking.useDHCP=true (scripted dhcpcd) — Nix warns both may manage interfaces. Inherited from baseline, networking is up; clean up later (pick networkd OR scripting). Tracked, non-blocking.