What broke

The runner advertised ubuntu-latest:host while running jobs directly on macOS. The host execution mode uses the runner machine, so the Ubuntu label did not create a Linux environment. Workflow jobs that requested Ubuntu could therefore execute on Darwin.

How it showed

At 17:03 CEST on 2026-10-10, the scheduled check reported:

runner labels [ubuntu-latest:host] do not match host os=darwin

Gitea accepted the label and assigned jobs to the Mac runner.

What was watching

Synthetic monitoring ran every five minutes and compared the runner's advertised host label with uname. It fired the alert above and paged the operator.

Gitea's task scheduler did not validate that a host-mode label described the machine that would execute the job. That boundary had no blocking invariant.

Where it sits

This is a runtime and invariants failure: a runner's host label must agree with the host that executes its jobs. Runtime invariants had no blocking assertion at the scheduler boundary. Synthetic monitoring was present and detected the mismatch after registration.

What we did

The Mac runner now advertises macos-arm64:host. A separate runner inside Colima advertises ubuntu-latest and executes jobs in Linux containers. Active workflows that use station-local tools, services, or deploy keys request the Mac label. Portable suites remain on Ubuntu. Their Go and uv prerequisites are set up explicitly.

What now fails loudly

runner-label-check reads the active runner configuration, ignores docker:// labels when comparing host operating systems, and pages when the Mac host runner has no matching macOS :host label.