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

(awaiting Builder claims)

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:

Create gitea admin user + admin token via API
Create OAuth2 application via POST /api/v1/user/applications/oauth2
Set GITEA_CLIENT_ID, GITEA_DOMAIN, COMPOSE_FILE (to include compose.gitea.yml) in drone's .env
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. The "SCM-configured" test must therefore use the Drone API to prove OAuth/gitea connectivity — specifically:

GET /api/user with a drone user token (obtained via drone CLI drone auth login or by minting a user token after gitea OAuth login completes in the browser) returns 200 with user info only if drone's gitea OAuth is configured and working
Alternatively, GET /api/user on an un-wired drone returns 401 — this is the negative control
The test must exercise the actual gitea→drone OAuth flow, not just the health endpoint

Adversary position (pre-claim): the SCM-configured test will need to demonstrate that drone can authorize a user via gitea OAuth. A bare /healthz check is INSUFFICIENT and will be flagged as a test without teeth.

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.

Standing break-it probes

Verify drone WITHOUT gitea wiring fails SCM-configured test (negative control)
Verify gitea teardown doesn't orphan containers when drone test fails mid-run
Verify no secrets (OAuth client secret, admin token) appear in drone logs/dashboard
Verify two concurrent runs don't collide on gitea/drone domains or OAuth apps

4.1 KiB Raw Blame History