bug(workflows): deploy workflows use runs-on: self-hosted but runner advertises ubuntu-latest — jobs never picked up #508

New Issue

marcel · 2026-05-11T16:15:46+02:00

marcel commented

2026-05-11 16:15:46 +02:00

Summary

.gitea/workflows/nightly.yml and release.yml both have runs-on: self-hosted. Our gitea-runner advertises labels ubuntu-latest / ubuntu-24.04 / ubuntu-22.04 — no runner has the self-hosted label. Result: dispatched deploy jobs sit in the queue indefinitely.

Reproduction

$ # dispatch nightly via workflow_dispatch
$ # then:
$ docker exec gitea-runner cat /data/.runner | jq .labels
[
  "ubuntu-latest:docker://docker.gitea.com/runner-images:ubuntu-latest",
  "ubuntu-24.04:docker://docker.gitea.com/runner-images:ubuntu-24.04",
  "ubuntu-22.04:docker://docker.gitea.com/runner-images:ubuntu-22.04"
]
$ # job stays queued; runner logs show no task pickup

Impact

First production deploy of #497 cannot start. Run 1483 (workflow_dispatch nightly) sat queued until cancelled. Re-dispatched run 1492 has the same outcome.
The CI jobs run fine because they use runs-on: ubuntu-latest, which matches.

Fix

Change runs-on: self-hosted → runs-on: ubuntu-latest in both deploy workflows. The runner is genuinely self-hosted (DooD socket mounted, joined to gitea_gitea net, single-tenant per ADR-011) — the self-hosted token in runs-on was just an unconfirmed label name.

Alternative considered: re-register the runner with a self-hosted label. Rejected as operationally invasive (would require editing /data/.runner and restarting), with no upside — ADR-011's single-tenant promise is about the repo, not the label.

Discovered

While running nightly.yml for the first staging deploy after #497 / #499 landed.

## Summary `.gitea/workflows/nightly.yml` and `release.yml` both have `runs-on: self-hosted`. Our `gitea-runner` advertises labels `ubuntu-latest / ubuntu-24.04 / ubuntu-22.04` — no runner has the `self-hosted` label. Result: dispatched deploy jobs sit in the queue indefinitely. ## Reproduction ``` $ # dispatch nightly via workflow_dispatch $ # then: $ docker exec gitea-runner cat /data/.runner | jq .labels [ "ubuntu-latest:docker://docker.gitea.com/runner-images:ubuntu-latest", "ubuntu-24.04:docker://docker.gitea.com/runner-images:ubuntu-24.04", "ubuntu-22.04:docker://docker.gitea.com/runner-images:ubuntu-22.04" ] $ # job stays queued; runner logs show no task pickup ``` ## Impact - **First production deploy of #497 cannot start.** Run 1483 (workflow_dispatch nightly) sat queued until cancelled. Re-dispatched run 1492 has the same outcome. - The CI jobs run fine because they use `runs-on: ubuntu-latest`, which matches. ## Fix Change `runs-on: self-hosted` → `runs-on: ubuntu-latest` in both deploy workflows. The runner is genuinely self-hosted (DooD socket mounted, joined to `gitea_gitea` net, single-tenant per ADR-011) — the `self-hosted` token in `runs-on` was just an unconfirmed label name. Alternative considered: re-register the runner with a `self-hosted` label. Rejected as operationally invasive (would require editing `/data/.runner` and restarting), with no upside — ADR-011's single-tenant promise is about the repo, not the label. ## Discovered While running `nightly.yml` for the first staging deploy after #497 / #499 landed.

marcel referenced this issue from a commit

2026-05-11 16:16:23 +02:00

fix(workflows): match runner label — runs-on ubuntu-latest, not self-hosted

marcel referenced a pull request that will close this issue

2026-05-11 16:16:32 +02:00

fix(workflows): match runner label — runs-on ubuntu-latest (#508) #509

marcel closed this issue

2026-05-11 16:18:41 +02:00

Sign in to join this conversation.