fix: remote-backend scale-up relies on workflow_job webhooks, which Forgejo never sends #56

New issue

Open

opened 2026-09-27 20:10:10 +00:00 by rcsheets · 0 comments

rcsheets commented

2026-09-27 20:10:10 +00:00

Owner

The webhook receiver's scale-up path (internal/webhook/receiver.go) waits for workflow_job events with action queued, then annotates matching pools with requested-replicas, which the remote backend reads to scale up from minReplicas.

Forgejo never sends workflow_job events. Checked against Forgejo 16 source: the only Actions webhook events are action_run_success, action_run_failure and action_run_recover (modules/webhook/type.go), all fired when a run finishes. The receiver was modeled on GitHub/Gitea. So remote-backend pools never scale above minReplicas, and the completed path never fires either.

Proposal: move the remote backend onto the same mechanism Kubernetes ephemeral pools use (#30): poll GET …/actions/runners/jobs?labels=… in the pool's scope for waiting jobs, and scale on those. Then retire the workflow_job receiver, or repurpose it to trigger an immediate reconcile on action_run_* events if that turns out to be useful.

Found while designing ephemeral mode for #30.

🤖 Generated with Claude Code

The webhook receiver's scale-up path (`internal/webhook/receiver.go`) waits for `workflow_job` events with action `queued`, then annotates matching pools with `requested-replicas`, which the remote backend reads to scale up from `minReplicas`. **Forgejo never sends `workflow_job` events.** Checked against Forgejo 16 source: the only Actions webhook events are `action_run_success`, `action_run_failure` and `action_run_recover` (`modules/webhook/type.go`), all fired when a run *finishes*. The receiver was modeled on GitHub/Gitea. So remote-backend pools never scale above `minReplicas`, and the `completed` path never fires either. **Proposal:** move the remote backend onto the same mechanism Kubernetes ephemeral pools use (#30): poll `GET …/actions/runners/jobs?labels=…` in the pool's scope for waiting jobs, and scale on those. Then retire the `workflow_job` receiver, or repurpose it to trigger an immediate reconcile on `action_run_*` events if that turns out to be useful. Found while designing ephemeral mode for #30. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

rcsheets referenced this issue from a commit

2026-09-28 01:12:38 +00:00

feat(kubernetes): ephemeral pools, one runner per job

rcsheets referenced this issue

2026-09-28 01:12:59 +00:00

feat(kubernetes): ephemeral pools, one runner per job #57