infra/forgejo: raise LAN runner concurrency to 8 #43

Merged

admin_emi merged 1 commit from infra/forgejo-runner-capacity into main

2026-07-24 19:05:23 +00:00

admin_emi commented

2026-07-24 19:04:48 +00:00

Owner

Summary

A single PR push fires pr-build, secrets-guard, and shell-lint as three independent workflows with no dependency between them, so runner.capacity (previously 3, an undocumented hand-tune of the tool's default of 1) already saturates before build-backend/build-frontend/validate-observability get a slot — even though the runner host has 16 cores / 34GB free sitting idle.
Raise capacity to 8, track it in register-lan-runner.sh (override via CAPACITY=) so a re-provision doesn't silently regress to the tool's default.
Document why more throughput should mean raising this number or adding a second runner on the desktop — not a runner on prod/beta: docker_host: automount gives job containers the host's own Docker socket, so on a live app or Forgejo host any CI job would get root-equivalent access to whatever else is running there. An earlier stack revision actually ran the runner on beta and was reverted for this reason.

Status

Already applied live on the desktop runner (config.yaml capacity: 8, restarted, active) — this PR makes the repo match reality.

Test plan

Runner restarted with capacity 8, service active
forgejo-runner generate-config confirmed default is capacity: 1, so the sed pattern matches

## Summary - A single PR push fires `pr-build`, `secrets-guard`, and `shell-lint` as three independent workflows with no dependency between them, so `runner.capacity` (previously 3, an undocumented hand-tune of the tool's default of 1) already saturates before `build-backend`/`build-frontend`/`validate-observability` get a slot — even though the runner host has 16 cores / 34GB free sitting idle. - Raise capacity to 8, track it in `register-lan-runner.sh` (override via `CAPACITY=`) so a re-provision doesn't silently regress to the tool's default. - Document why more throughput should mean raising this number or adding a second runner on the desktop — not a runner on prod/beta: `docker_host: automount` gives job containers the host's own Docker socket, so on a live app or Forgejo host any CI job would get root-equivalent access to whatever else is running there. An earlier stack revision actually ran the runner on beta and was reverted for this reason. ## Status Already applied live on the desktop runner (`config.yaml` capacity: 8, restarted, active) — this PR makes the repo match reality. ## Test plan - [x] Runner restarted with capacity 8, service active - [x] `forgejo-runner generate-config` confirmed default is `capacity: 1`, so the sed pattern matches

admin_emi added 1 commit 2026-07-24 19:04:50 +00:00

infra/forgejo: raise LAN runner concurrency, document why prod/beta aren't candidates

PR build (required check) / changes (pull_request) Successful in 6s

Details

secrets-guard / encrypted (pull_request) Successful in 5s

Details

PR build (required check) / build-backend (pull_request) Has been skipped

Details

shell-lint / shellcheck (pull_request) Successful in 8s

Details

PR build (required check) / build-frontend (pull_request) Has been skipped

Details

PR build (required check) / validate-observability (pull_request) Has been skipped

Details

PR build (required check) / gate (pull_request) Successful in 3s

Details

1660de6cc6

A single PR push fires pr-build, secrets-guard, and shell-lint as three
independent workflows with no dependency between them, so the previous
capacity (3, an earlier undocumented hand-tune of the tool's default of
1) already serializes build-backend/build-frontend/validate-observability
behind them even with 16 idle cores on the runner host. Raise to 8 and
track it in register-lan-runner.sh so a re-provision doesn't silently
drop back to the default.

Also document why more capacity belongs on the desktop rather than a
runner on prod/beta: docker_host: automount gives job containers the
host's own Docker socket, which on a live app or Forgejo host means any
CI job gets root-equivalent access to what else is running there. An
earlier stack revision did run the runner on beta and was reverted for
this reason.