personal_infra/ansible/roles/forgejo_runner/tasks/main.yml

---
# import_tasks, not include_tasks: these are unconditional phases, and static
# imports are visible to `--list-tasks`. That matters because the task list is
# how this refactor was verified against the playbook it replaced.
- ansible.builtin.import_tasks: prerequisites.yml
- ansible.builtin.import_tasks: install.yml
# Before configure.yml and service.yml: config.yml names the dind daemon and
# forgejo-runner.service Requires= its unit, so it has to exist by then.
- ansible.builtin.import_tasks: dind.yml
- ansible.builtin.import_tasks: configure.yml
- ansible.builtin.import_tasks: service.yml
- ansible.builtin.import_tasks: healthcheck.yml
forgejo-runner: convert to a role, de-Uptime-Kuma the health check 409-line playbook becomes a 16-line playbook plus a 318-line role with phases split across tasks/{prerequisites,install,configure,service,healthcheck}.yml and four templates. forgejo_runner_vars.yml is deleted; its content is the role's defaults. Applies the Plan 6 Stage 0 decision: keep whatever determines whether the service is healthy, drop the Uptime Kuma specifics, make the reporting point pluggable. Gone from the role: the embedded Python that created monitors over the Kuma API, the /tmp credentials file, token extraction, the systemd Environment= rewrite, and 8 `when: uptime_kuma_enabled` guards. What remains is the check itself, its log, the systemd unit and timer, and an honest exit code - `systemctl is-failed forgejo-runner-healthcheck.service` now answers the question with no monitoring system involved at all. Reporting is one variable, healthcheck_push_url, empty by default. Any endpoint that accepts an HTTP ping plugs in there. A pull-based monitor wants it left empty and reads unit state instead. PREMISE CORRECTION: Uptime Kuma is NOT dead. Plan 3 recorded "48 push timers curling an endpoint that no longer answers" and Plan 6 said the check had "nowhere to report to". Both wrong - 24+ push scripts across 11 hosts are pushing successfully right now (HTTP 200). Only the Ansible code and the vault credentials were decommissioned; the service never stopped. So the existing push URLs were harvested into a vaulted healthcheck_push_urls dict and are preserved, keeping this refactor behaviour-neutral. Retiring Kuma stays a deliberate act rather than a side effect. PLAN_3 and PLAN_6 are corrected. Verified: - task-list diff vs the old playbook shows ONLY the five Kuma tasks removed, everything else identical and in the same order - first run ok=22 changed=1 (the rewritten health script); both systemd units and forgejo-runner.service came back ok, so the templates reproduce the previous files byte-for-byte - second run ok=22 changed=0, fully idempotent - still reports "Ping sent successfully (HTTP 200)" from a script containing zero Uptime Kuma references - the 4 skipped tasks are genuine already-configured guards, checked not assumed Two things for the next service: - import_tasks, not include_tasks. Dynamic includes are opaque to --list-tasks, which is the primary verification tool here; the first attempt produced a useless diff. - `Assert runner is running` was guarded by uptime_kuma_enabled and so had not run since the decommissioning. It is not monitoring, it is the deployment checking its own work - the deprecation banner swept it up with the Kuma plumbing, and a runner that failed to start was deploying "successfully" in silence. Ungated now. The banner was applied to contiguous blocks, so read every uptime_kuma_enabled guard and ask whether it is monitoring or deployment. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-12 18:15:29 +02:00			`---`
			`# import_tasks, not include_tasks: these are unconditional phases, and static`
			# imports are visible to `--list-tasks`. That matters because the task list is
			`# how this refactor was verified against the playbook it replaced.`
			`- ansible.builtin.import_tasks: prerequisites.yml`
			`- ansible.builtin.import_tasks: install.yml`
forgejo-runner: give CI jobs a Docker daemon of their own jar-lid-archive's CI needs `docker build` and `docker compose`, and job containers had no Docker at all: config.yml carried the stock `container.docker_host: "-"`, which is precisely "find a daemon for the runner and do not let jobs near it". A docker:dind sidecar now runs on forgejo-runner-box, published on 127.0.0.1 only, and jobs build against that instead of the host daemon. Following Forgejo's own admin docs, which make the point that this is THREE settings and not one: forgejo-dind.service a privileged docker:dind on the host daemon container.docker_host tcp://127.0.0.1:2376 - where the runner CREATES job containers runner.envs.DOCKER_HOST + tcp://forgejo-dind.docker.internal:2375 - container.options how a job, from INSIDE dind, reaches it The third is the one that is easy to miss and fails identically to having done nothing: for a tcp:// docker_host the runner mounts nothing into the job container, so the job still finds no daemon. The two addresses differ because they are used from different places - the runner is a process on the host; a job container is inside dind, where 127.0.0.1 is itself. `host-gateway` is expanded by the daemon creating the container, which is dind, so it lands on dind's own bridge gateway. Verified on the box, along the exact path a job takes - a container on a user-defined network, with the same --add-host and DOCKER_HOST the runner will set: the name resolves to 172.20.0.1, `docker version` returns the dind server, and `docker build` succeeds. The host daemon runs forgejo-dind and nothing else. config.yml had to become a template to do any of this. It was previously `generate-config` run once on first deploy and never touched again, so the repo had no say in its contents. Every value was transcribed from the live file and diffed against it key by key: with dind disabled, 30 of 30 identical. Two deliberate differences - runner.envs drops A_TEST_ENV_NAME_1/2, upstream's placeholders, which were being injected into every job here; and the upstream comment blob is gone. Because the file is managed now it also gets a restart handler, the absence of which has bitten this repo before. Things deliberately chosen rather than defaulted into: - the flag lives in the playbook, not the role defaults, so the role's default stays the configuration this host has always run and turning it off is one line. Disabling it also tears the units down rather than just skipping them. - dind is a hard Requires= of forgejo-runner, and its unit stays in "activating" until the daemon answers. A dead dind is then one red unit instead of a green runner failing every job it claims. - the healthcheck and monitored_services learned about dind for the same reason: runner up + dind down is the interesting failure and it was previously invisible. - /var/lib/docker is a named volume, or every image is re-pulled on each container recreation; a weekly prune keeps that from growing forever. - dind's network pool is pinned to 172.20.0.0/14. Docker's stock pool reaches into 192.168.x, and act_runner creates a network per job, so a job could eventually allocate this LAN's subnet and lose the route to every box on it. Note this runner is SHARED - arbret, arbret-biz, arbretdos and arbret-ops build here too, far more often, and docker_host is per-runner not per-repo. Their workflows are unchanged but their next run pulls images into a cold cache. Job images still need a docker client of their own: node:{20,22}-bookworm ship none. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-27 22:32:08 +02:00			`# Before configure.yml and service.yml: config.yml names the dind daemon and`
			`# forgejo-runner.service Requires= its unit, so it has to exist by then.`
			`- ansible.builtin.import_tasks: dind.yml`
forgejo-runner: convert to a role, de-Uptime-Kuma the health check 409-line playbook becomes a 16-line playbook plus a 318-line role with phases split across tasks/{prerequisites,install,configure,service,healthcheck}.yml and four templates. forgejo_runner_vars.yml is deleted; its content is the role's defaults. Applies the Plan 6 Stage 0 decision: keep whatever determines whether the service is healthy, drop the Uptime Kuma specifics, make the reporting point pluggable. Gone from the role: the embedded Python that created monitors over the Kuma API, the /tmp credentials file, token extraction, the systemd Environment= rewrite, and 8 `when: uptime_kuma_enabled` guards. What remains is the check itself, its log, the systemd unit and timer, and an honest exit code - `systemctl is-failed forgejo-runner-healthcheck.service` now answers the question with no monitoring system involved at all. Reporting is one variable, healthcheck_push_url, empty by default. Any endpoint that accepts an HTTP ping plugs in there. A pull-based monitor wants it left empty and reads unit state instead. PREMISE CORRECTION: Uptime Kuma is NOT dead. Plan 3 recorded "48 push timers curling an endpoint that no longer answers" and Plan 6 said the check had "nowhere to report to". Both wrong - 24+ push scripts across 11 hosts are pushing successfully right now (HTTP 200). Only the Ansible code and the vault credentials were decommissioned; the service never stopped. So the existing push URLs were harvested into a vaulted healthcheck_push_urls dict and are preserved, keeping this refactor behaviour-neutral. Retiring Kuma stays a deliberate act rather than a side effect. PLAN_3 and PLAN_6 are corrected. Verified: - task-list diff vs the old playbook shows ONLY the five Kuma tasks removed, everything else identical and in the same order - first run ok=22 changed=1 (the rewritten health script); both systemd units and forgejo-runner.service came back ok, so the templates reproduce the previous files byte-for-byte - second run ok=22 changed=0, fully idempotent - still reports "Ping sent successfully (HTTP 200)" from a script containing zero Uptime Kuma references - the 4 skipped tasks are genuine already-configured guards, checked not assumed Two things for the next service: - import_tasks, not include_tasks. Dynamic includes are opaque to --list-tasks, which is the primary verification tool here; the first attempt produced a useless diff. - `Assert runner is running` was guarded by uptime_kuma_enabled and so had not run since the decommissioning. It is not monitoring, it is the deployment checking its own work - the deprecation banner swept it up with the Kuma plumbing, and a runner that failed to start was deploying "successfully" in silence. Ungated now. The banner was applied to contiguous blocks, so read every uptime_kuma_enabled guard and ask whether it is monitoring or deployment. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-12 18:15:29 +02:00			`- ansible.builtin.import_tasks: configure.yml`
			`- ansible.builtin.import_tasks: service.yml`
			`- ansible.builtin.import_tasks: healthcheck.yml`