personal_infra/ansible/roles/forgejo_runner
counterweight 954b683c71
ansible: delete the duplicated vars files, move globals to group_vars/all
Three files existed only as second copies of things group_vars/all already
auto-loads, and 34 playbooks named them in vars_files: - which outranks
group_vars, so the copies won. The day someone edited one and not the other,
those plays would silently keep the stale value. infra_vars.yml was already
drifting: group_vars/all/main.yml had grown age_backup_recipient and
backup_pull_public_key that it lacked.

  infra_vars.yml          - a strict subset of group_vars/all/main.yml
  infra_secrets.yml       - decrypts byte-identical to group_vars/all/vault.yml
  infra_secrets.yml.example - documented Uptime Kuma credentials as the reason
                              the file exists, which stopped being true

Deleted, along with 62 vars_files entries across 34 playbooks (12 of which
named ../../group_vars/all/main.yml directly - same defect, a vars_files entry
duplicating an auto-loaded file at higher precedence than the file itself).

Checked before touching anything: infra_secrets.yml was listed LAST in 10 plays,
after services_config.yml, so removal would flip precedence if the two shared a
key. They share none, and neither does services_config.yml with
group_vars/all/main.yml, so the removal is provably inert.

services_config.yml was the last one standing. It held four unrelated things:

  caddy_sites_dir            - an identical copy of roles/caddy_site/defaults/.
                               Deleted; the role default is now the only one.
  *.tailscale_hostname (x3)  - a THIRD copy of each box's identity, which
                               inventory.ini already holds as ansible_host.
                               Deleted. Edge plays now read
                               hostvars['<host>'].ansible_host - verified an
                               edge play resolves that with nothing loaded and
                               the other host in no play. Three copies of one
                               name is how bitcoin_rpc_host ended up labelled
                               "knots_box" while pointing at fulcrum-box.
  subdomains, ntfy topic,    - genuinely global: their readers span managed,
  headscale namespace          monitoring, vpn_control and edge, so no single
                               group covers them. Moved to group_vars/all/main.yml
                               where they auto-load. The ntfy_topic and
                               headscale_namespace indirection through
                               service_settings collapses to the global name.
  the four cross-host ports  - the only entries with a real justification.
                               Left in place; they move in the next commit.

Also dead, all Uptime Kuma residue or duplication:
  phoenixd_monitor_name, forgejo_runner healthcheck_timeout_seconds/retries,
  fulcrum_tailscale_hostname, and bitcoin_knots_version - the last being a
  v-prefixed copy of bitcoin_knots_version_short that nothing read, two
  hand-maintained copies of one version string.

Corrected a false comment: services_config.yml claimed the uptime_kuma subdomain
"no longer resolves to anything". It resolves to 164.92.239.72 and answers HTTP
302, and 11 playbooks still template it. Same wrong premise as PLAN_3.

Verification: all 37 playbooks' --list-tasks output is byte-identical before and
after. A probe resolving all 22 values services_config.yml used to supply returns
21 identical and one intended deletion (caddy_sites_dir, now role-only - confirmed
the role still resolves it: "Ensure Caddy sites-enabled directory exists" comes
back ok against the real path). memos check-diff identical before and after.
Syntax passes on every playbook.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-13 20:58:46 +02:00
..
defaults ansible: delete the duplicated vars files, move globals to group_vars/all 2026-09-13 20:58:46 +02:00
tasks forgejo-runner: convert to a role, de-Uptime-Kuma the health check 2026-09-12 18:15:29 +02:00
templates forgejo-runner: convert to a role, de-Uptime-Kuma the health check 2026-09-12 18:15:29 +02:00
README.md forgejo-runner: convert to a role, de-Uptime-Kuma the health check 2026-09-12 18:15:29 +02:00

forgejo_runner

Installs and runs a Forgejo Actions runner, registers it with the Forgejo instance, and keeps a health check on a systemd timer.

Converted from deploy_forgejo_runner_playbook.yml (409 lines) under Plan 6. The playbook is now 16 lines.

Phases

tasks/main.yml imports five files in order:

prerequisites.yml Docker must be present
install.yml binary, system user, working directory
configure.yml config file, registration with the instance
service.yml systemd unit, start, assert it came up
healthcheck.yml check script, unit, timer

import_tasks, not include_tasks — static imports are visible to --list-tasks, which is how the conversion was verified against the playbook it replaced.

Monitoring: one variable, no product knowledge

This role contains nothing specific to any monitoring system. What used to be here — an ~80-line embedded Python script creating monitors over the Uptime Kuma API, a /tmp credentials file, token extraction, a systemd Environment= rewrite, and 8 when: uptime_kuma_enabled guards — is gone.

What remains answers the actual question, is this service healthy, and records it two ways:

  • the exit code, which systemd keeps: systemctl is-failed forgejo-runner-healthcheck.service is a complete answer with no monitoring system involved at all;
  • a log file at {{ healthcheck_log_file }}.

To report health somewhere, set one variable:

healthcheck_push_url: "https://example/api/push/TOKEN"

Any endpoint accepting an HTTP ping works. Empty (the default) means check, log, exit honestly, report nowhere — which is also the right setting for a pull-based monitor like Prometheus' textfile collector, since that reads unit state instead.

The push URL is a credential (anyone holding it can forge an "up"), so callers pass it from the vault rather than committing it.

One behaviour change, deliberate

Assert runner is running used to be guarded by uptime_kuma_enabled, so it never ran. It is not a monitoring task — it is the deployment checking its own work — and the deprecation banner swept it up by mistake. It is ungated here, which means a runner that fails to start now fails the play instead of deploying "successfully" in silence.