The Gitea Actions runner

Gitea ships a CI system that speaks the same workflow syntax as GitHub Actions. To actually run jobs you register a runner — and that's a dedicated VM here (GIT-Runner, 10.100.100.11).

Why a separate VM rather than running builds in the cluster? Builds are bursty, disk-hungry, and occasionally want privileged operations. Keeping them on their own box means a heavy build can't disturb cluster workloads, and the build host can have Docker installed without that being a concern for the cluster nodes.

The runner is the act_runner agent (the project was renamed gitea-runner at v1.0), installed as a systemd service so it survives reboots and restarts on failure. It registers against the Gitea instance and then sits waiting for jobs.

GIT-Runner (10.100.100.11)
  - Docker engine (for building images)
  - gitea-runner  (systemd service)  -> registered to git.example.com
  - labels: ubuntu-24.04, ubuntu-26.04  (which job images it offers)

Why we use this: a build runner is just a worker that polls for work. Running it as a plain systemd service on a dedicated VM is about as simple and debuggable as CI gets — when a build misbehaves you SSH to one box and read one service's logs.