Deep, code-grounded tree-docs guidebook under vibe/guidebooks/factory-provisioning/, explored from the actual playbooks/roles and tofu code: - Hub: the two provisioning engines (operator-run Ansible vs CI-applied OpenTofu), a green-field bring-up flow, master index, maintenance rule. - ansible/ sub-tree: ordered pages 01-system .. 06-recover, an inventory & variables concept page, and a Tier-1/Tier-2 roles reference (hashicorp_vault, step_ca, crowdsec, pihole, deploy_docker_compose + the gitea_* family and helpers). - opentofu/ sub-tree: factory-iac (Cloudflare/OVH/GCP/Gitea/Vault edge + cloudflare_token module), postgres-iac (per-app DB/role/pgbouncer lookup), ci-apply-flow (Gitea OIDC-JWT -> Vault -> auto-approve apply). Cross-linked bidirectionally with the lab-ecosystem guidebook and the safe-env ADR/PRD (the sandbox rehearses exactly these engines). 14 mermaid diagrams MCP-validated; zero dead links. Authored by the Lab Cartographer cohort. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.1 KiB
vibe > Guidebooks > Factory provisioning > Ansible > 03 · CI/CD
03 · CI/CD — Gitea Actions runners
Note
Status: ✅ active · Last Updated: 2026-06-23 Upstream: Ansible sub-hub · 02 · Setup Downstream: 04 · Tools Related: Lab ecosystem · 01 factory (ArgoCD caveat) · Roles reference · Inventory & variables
What it does
03 · CI/CD registers and deploys the Gitea Actions runner (act_runner) on every Pi that is not the Gitea host, so CI jobs have executors. The whole stage is one playbook, playbooks/03_cicd.yml — there is no stage subdirectory.
It targets raspberries:&local:!gitea, i.e. the raspberries that are local minus the gitea group. Since gitea resolves to pi2, the runner lands on pi1 and pi3 (see Inventory & variables).
Steps
| # | Task / role | Purpose | Key detail |
|---|---|---|---|
| 1 | role arcodange.factory.gitea_token |
Mint a gitea_api_token for later API use. |
Reused across the collection (see Roles reference). |
| 2 | gitea actions generate-runner-token (delegated to the Gitea host) |
Fetch a runner registration token by docker exec-ing into the gitea container. |
delegate_to: groups.gitea[0] |
| 3 | role arcodange.factory.deploy_docker_compose |
Render the act_runner Compose stack with the registration token, instance URL, runner name, and labels. |
image gitea/act_runner:latest; labels point at runner-images:ubuntu-latest-ca |
| 4 | community.docker.docker_compose_v2 (down→up loop) |
Apply the stack: a loop: [absent, present] recreates the runner so token/label changes take effect. |
cache dirs under /mnt/arcodange/gitea-runner-* |
The runner registers with GITEA_INSTANCE_URL: http://<gitea-host>:3000, names itself arcodange_global_runner_<host>, and advertises the ubuntu-latest / ubuntu-latest-ca labels — both mapped to the CA-trusting image built back in 01 · System. It mounts the Docker socket and the host CA store (/etc/ssl/certs, /usr/local/share/ca-certificates) so jobs trust internal TLS, and runs with insecure: true against the Gitea TLS endpoint.
Gotchas
Warning
ArgoCD is present in design but not deployed. The factory pipeline intends
03_cicdto also bring up ArgoCD (the app-of-apps), but that step is commented out / not currently deployed in-cluster — this stage only deploys the Gitea runners. Treat ArgoCD as "designed, not live" until the install is enabled. See the ArgoCD caveat in lab-ecosystem · 01 factory.
Warning
The registration token is single-use and host-delegated. Step 2 generates a fresh token every run via the Gitea container, so the runner re-registers on each apply. If the Gitea host (
pi2) is down, token generation fails and no runner can register.