cc-ci/machine-docs/REVIEW-drone.md

REVIEW — phase drone (drone enrollment with gitea SCM dep)

Adversary: Adversary loop / Claude Phase plan: /srv/cc-ci/cc-ci-plan/plan-phase-drone-enroll.md Started: 2026-06-11T21:30Z

---

Verdicts

M1 PASS @2026-06-11T22:22Z

Build: manual run 5, host cc-ci, repo head 0aa46db
Evidence source: /tmp/drone-m1-run5.log + /var/lib/cc-ci-runs/manual/results.json on cc-ci
Level: 5 of 5

Adversary verification steps (all PASS):

1. Results JSON independently read: level=5, install:pass, upgrade:pass, custom:pass, lint:pass, backup_restore:skip (intentional, reason="not backup-capable"), clean_teardown:True, no_secret_leak:True, skips.unintentional:[] ✅

2. SCM-configured test has teeth (ADV-drone-01 fix): Test ran against dep gitea at gite-557a83.ci.commoninternet.net (NOT production git.autonomic.zone). OAuth2 app client_id=2a4dfaba-f8d5-4641-b860-b56bee414c14 created by dep provisioning, wired by install_steps.sh, verified by test assertion actual_client_id == expected_client_id. A drone without gitea wiring would redirect to GitHub or 200 — test would fail. ✅

3. DG4.1 satisfied: deploy-count = 2 (expect 2) — recipe + gitea dep both counted. No !! error lines in run summary. ✅

4. ADV-drone-02 CLOSED: Fallback teardown in finally else-branch (0aa46db) confirmed in code (line 1224-1240). Two unit tests confirm data flow. TeardownError suppressed in fallback (pragmatic — run already fails on deps-not-ready). Teardown-sacred §9 satisfied. ✅

5. ADV-drone-03 CLOSED: _count_deploy=False removed from deps.py:deploy_deps (5384f5c). Builder fixed before formal filing. Run 5 confirms DG4.1 passes. ✅

6. Unit tests 19/19 PASS cold: Independently verified on cc-ci. Covers gitea/drone recipe_meta loading, _enrich_deps_with_sso routing, SCM redirect assertions (4 scenarios), deps state fallback teardown. ✅

7. Backup structural skip: PARITY.md documents justification. Results.json confirms skips.intentional.backup_restore = "not backup-capable (no backupbot labels / declared)". No unintentional skips. ✅

8. No open adversary findings: ADV-drone-01 CLOSED (verified commit 7e7e84d), ADV-drone-02 CLOSED (verified commit 0aa46db), ADV-drone-03 CLOSED (verified commit 5384f5c). ✅

M1 PASS. Builder may proceed to M2 (recipe mirrors + !testme CI run).

---

M2 PASS @2026-06-11T22:30Z

Build: #506 on drone.ci.commoninternet.net, event=custom (bridge-triggered !testme)
PR: recipe-maintainers/drone #1 (testme-1.9.0-cc-ci @ 049438e1cb47)
Timestamp: 2026-06-11T22:21Z–22:23Z

Adversary verification steps (all PASS):

1. Results JSON independently read from /var/lib/cc-ci-runs/506/results.json: level=5, install:pass, upgrade:pass, backup:skip, restore:skip, custom:pass, lint:pass, backup_restore:skip intentional ("not backup-capable"), clean_teardown:True, no_secret_leak:True, skips.unintentional:[], pr:1, ref:049438e1cb47 ✅

2. Bridge-triggered independently confirmed via Drone API: event:custom, status:success, params:{PR:'1', RECIPE:'drone', REF:'049438e1cb473626f23f7b076ca9d880b50a69f1', SRC:'recipe-maintainers/drone'}, sender:autonomic-bot. Not a push event; not a manual run — genuine bridge !testme trigger. ✅

3. POLL_REPOS verified in nix/modules/bridge.nix: recipe-maintainers/drone present in the POLL_REPOS csv list. ✅

4. Screenshot (drone-m2-build506.png) visually inspected: Real drone landing page — "Hello, Welcome to Drone. You will be redirected to your source control management system to authenticate." + CONTINUE button. Not blank/placeholder. ✅

5. Gitea dep provisioned per-run (not production): STATUS-drone.md confirms gitea dep at gite-4c9694.ci.commoninternet.net, OAuth2 app client_id=d144083e-5ba5-4d1e-aed2-5e8f8331923a created per-run. Not git.autonomic.zone. ✅

6. DEFERRED build-creation gap — §7.1 sign-off: Per DEFERRED.md (2026-05-29 Q4.10), the drone scope was always "MAXIMAL SUBSET (drone boots with gitea SCM: install+upgrade+health+SCM-configured) + Adversary §7.1 sign-off on the build-creation gap." M2 proves the maximal subset (build #506, L5, all mandatory tiers). The build-creation API gap (creating/running actual CI pipelines via drone's own API — needs a drone OAuth token + .drone.yml + webhook trigger) is accepted as a genuine deferral: disproportionate to the current scope, requires infrastructure not yet in place, and is not a recipe gap. §7.1 SIGNED OFF. DEFERRED item updated. ✅

M2 PASS. Phase drone DONE. PR open for operator merge.

---

Pre-verification probes (Adversary-initiated, before any Builder claim)

P0 verification — /etc/timezone on cc-ci host

Verified: 2026-06-11T21:30Z

ssh cc-ci 'test -f /etc/timezone && cat /etc/timezone'
# → UTC
ssh cc-ci 'ls -la /etc/localtime /etc/timezone'
# → /etc/localtime -> /etc/zoneinfo/UTC
# → /etc/timezone -> /etc/static/timezone (content: UTC)

Result: P0 SATISFIED. Both /etc/timezone (content UTC) and /etc/localtime exist. The gitea recipe's bind mounts (/etc/timezone:ro and /etc/localtime:ro) will succeed. The host-config fix from commit 3bde76f is live.

Pre-probe: drone recipe versions

ssh cc-ci 'abra recipe versions drone --machine'

• Latest: 1.9.0+2.26.0 (drone/drone:2.26.0)
• Previous: 1.8.0+2.25.0 (drone/drone:2.25.0)
• Upgrade tier: viable (2 published versions; upgrade 1.8 → 1.9 is the natural choice)

Pre-probe: gitea recipe versions

ssh cc-ci 'abra recipe versions gitea --machine'

• Latest: 3.5.3+1.24.2-rootless (gitea + postgres)
• Previous: 3.5.2+1.24.2-rootless
• Gitea uses postgres by default (not sqlite3). The sqlite3 overlay exists but is non-default.
• The compose.sqlite3.yml sets GITEA_DB_TYPE=sqlite3 — if gitea is used as a dep without postgres, sqlite3 is the right choice (simpler dep deploy, less resource overhead).
• Upgrade tier: viable for gitea as a dep, but the phase plan scope only requires drone's upgrade tier. Gitea as a dep is deployed at the PR version; upgrade tier for the dep is out of scope per plan §1.

Pre-probe: drone recipe structure

The compose.gitea.yml overlay requires:

• GITEA_CLIENT_ID in .env
• GITEA_DOMAIN in .env
• client_secret swarm secret

The drone.env.tmpl conditionally injects DRONE_GITEA_CLIENT_SECRET from secret "client_secret" when DRONE_GITEA_CLIENT_ID is set. So the install hook must:

1. Create gitea admin user + admin token via API
2. Create OAuth2 application via POST /api/v1/user/applications/oauth2
3. Set GITEA_CLIENT_ID, GITEA_DOMAIN, COMPOSE_FILE (to include compose.gitea.yml) in drone's .env
4. Insert client_secret into drone's swarm secrets

Pre-probe: SCM-configured test teeth

The drone health endpoint /healthz returns OK regardless of SCM connectivity. This means a drone deployed WITHOUT gitea wiring would also pass a health check.

Verified the correct approach by querying the live drone instance:

curl -ski --max-redirs 0 https://drone.ci.commoninternet.net/login | grep location
# → location: https://git.autonomic.zone/login/oauth/authorize?client_id=ab4cdb9d-...&redirect_uri=...

GET /login (no-follow) → 303 redirect to <gitea-domain>/login/oauth/authorize?client_id=<id>&...

The correct "SCM-configured" test:

1. GET https://<drone-domain>/login with allow_redirects=False
2. Assert response is 302/303
3. Assert Location header starts with https://<gitea-domain>/login/oauth/authorize
4. Assert client_id query param matches the OAuth2 app we created in gitea

Why this has teeth: a drone deployed WITHOUT DRONE_GITEA_CLIENT_ID + DRONE_GITEA_SERVER (i.e., just the base compose.yml without compose.gitea.yml) would NOT redirect to the gitea domain — it would either error or redirect to a GitHub OAuth URL. The test is falsified by a misconfigured drone.

Adversary position (pre-claim): the SCM-configured test MUST use the /login redirect mechanism (or equivalent API proof of gitea wiring). A bare /healthz check is INSUFFICIENT and will be flagged as a test without teeth. The redirect target must point to the TEST-RUN gitea instance (the dep deployed by the harness), NOT to git.autonomic.zone (that would prove nothing).

Pre-probe: recipe mirrors

# drone: NOT mirrored on git.autonomic.zone/recipe-maintainers/drone (404)
# gitea: NOT mirrored on git.autonomic.zone/recipe-maintainers/gitea (404)

Both need to be mirrored before !testme can be used. Builder must follow the recipe mirror+PR flow (plan §4.1 / recipe-create-pr.md). This is expected and not a blocker — it's in scope.

---

Pre-claim findings (before M1 is claimed)

ADV-drone-01 — test_scm_configured redirect bug (CRITICAL)

Filed: 2026-06-11T21:37Z — see BACKLOG-drone.md for full details.

test_login_redirects_to_gitea_dep uses urllib.request.urlopen (follow-all-redirects). The chain is: drone /login → 303 → gitea OAuth authorize → 302 → gitea /user/login (unauthenticated). final_url is /user/login, so parsed.path == "/login/oauth/authorize" is always False. The test always fails, even for a correctly wired drone.

Fix: capture only drone's first redirect (no-follow pattern; capture Location header from 303).

This must be fixed before M1 can be claimed. If M1 is claimed without this fix, I will VETO.

RESOLVED @2026-06-11T21:52Z: Builder fixed in commit 7e7e84d. _CaptureOneRedirect raises HTTPError on 303, test reads Location header directly. Verified against live drone: captures /login/oauth/authorize path ✅. Unit tests 10/10 PASS cold. ADV-drone-01 CLOSED.

ADV-drone-02 — dep orphan on SSO-enrichment failure (MEDIUM)

Filed: 2026-06-11T22:10Z — see BACKLOG-drone.md for full details.

deps_state = {} is initialised empty in main(). _provision_deps calls deploy_deps first (gitea deployed + healthy, $CCCI_DEPS_FILE written), then _enrich_deps_with_sso. If the enrichment step raises (e.g. setup_gitea_oauth API call fails), _provision_deps re-raises and the deps_state = _provision_deps(...) assignment (line 1034) never completes. In the finally block, if deps_state: is falsy → dep teardown block is entirely skipped. The gitea container and volumes are orphaned at their deterministic domain.

Teardown-sacred (§9) violated in failure path.

Required fix before M1: option A (fallback teardown from $CCCI_DEPS_FILE in the finally block when deps_state is empty) or option B (separate deploy from enrichment tracking). See BACKLOG.

CLOSED @2026-06-11T22:22Z — commit 0aa46db; 19/19 unit tests pass; code verified. See BACKLOG-drone.md § ADV-drone-02.

ADV-drone-03 — DG4.1 counter mismatch; run always exits 1 with cold dep (CRITICAL)

Filed: 2026-06-11T22:15Z — see BACKLOG-drone.md for full details.

deps.py module docstring (line 19-20) says "Dep deploys DO count toward DG4.1; expected = 1 + deps_deployed_count." But deploy_deps passes _count_deploy=False → dep deploys never increment the counter. With gitea as a cold dep: actual=1, expected=2 → DG4.1 fires → overall = 1 → CI FAIL, even when all tiers pass and level=5 is reached.

Confirmed in Builder's run 4 log (/tmp/drone-m1-run4.log): all tiers green, L5, but deploy-count 1 != 2 (DG4.1 violation).

Fix: remove _count_deploy=False from deploy_deps (deps SHOULD count per the docstring and the expected formula). Update the stale comment that contradicts the module docstring.

CLOSED @2026-06-11T22:22Z — commit 5384f5c; Builder fixed before formal filing. Run 5 confirms DG4.1 PASS. See BACKLOG-drone.md § ADV-drone-03.

---

Standing break-it probes

• Verify drone WITHOUT gitea wiring fails SCM-configured test (negative control) — defer to M2 CI run; requires live deploy; structural analysis confirms install_steps.sh no-ops on absent deps file and test detects wrong netloc/path in redirect URL
• Verify gitea teardown doesn't orphan containers when drone test fails mid-run — structural PASS for normal test failures (finally block guaranteed); GAP filed as ADV-drone-02 for SSO-enrichment failure before deps_state populated
• Verify no secrets (OAuth client secret, admin token) appear in drone logs/dashboard — defer to M2 CI run; structural review of sso.py + install_steps.sh shows client_secret not printed in happy path; _scrub() + D6 redaction in run_redacted() provide belt-and-suspenders
• Verify two concurrent runs don't collide on gitea/drone domains or OAuth apps — structural PASS: domain is dep_domain(parent_recipe, pr, ref, dep_recipe) — hash of 4 inputs; two concurrent !testme runs on different PRs or refs produce distinct 6-hex domains; per-run ABRA_DIR isolation prevents recipe tree conflicts