31 lines
1.3 KiB
Markdown
31 lines
1.3 KiB
Markdown
Stateless Gitea runner scaler.
|
|
|
|
Design:
|
|
- Gitea emits `workflow_job` webhooks to `POST /webhooks/workflow-job`
|
|
- This service verifies the webhook signature and tracks queued jobs in Redis
|
|
- KEDA polls the gRPC external scaler API on port `50051`
|
|
- The scale target is `Deployment/act-runner`
|
|
|
|
Why this exists:
|
|
- The previous scaler read `gitea.db` from the `gitea-data` SQLite volume
|
|
- That coupled scaler scheduling and failover to the same `ReadWriteOnce` PVC as Gitea
|
|
- This redesign removes that PVC dependency entirely
|
|
|
|
Current assumptions:
|
|
- Gitea webhook payloads are GitHub-compatible enough to provide:
|
|
- `action`
|
|
- `workflow_job.id`
|
|
- `workflow_job.labels`
|
|
- `workflow_job.status`
|
|
- The label we currently care about is `ubuntu-latest`
|
|
|
|
Required wiring before production/staging rollout:
|
|
1. Build and publish `git.staging.jamkazam.com/seth/gitea-external-scaler:2.0.1`
|
|
2. Set a real `webhookSecret` in `runner-scaler.yaml`
|
|
3. Add repo or instance webhooks in Gitea that send `workflow_job` events to:
|
|
`http://gitea-external-scaler.jam-cloud-infra.svc.cluster.local:8080/webhooks/workflow-job`
|
|
4. Decide whether `act-runner` desired replicas should move to `0` in repo-managed state
|
|
|
|
Reference:
|
|
- Gitea docs recommend the `workflow_job` webhook to automate registration/startup of new runners.
|