Support multiple Forgejo runner registrations with shared controller capacity #8

New issue

Closed

opened 2026-10-19 18:36:22 +00:00 by thesimplekid · 0 comments

thesimplekid commented

2026-10-19 18:36:22 +00:00

Owner

Use case

Run CI for both a personal account and an organization on the same Forgejo instance using one Rith controller and one pool of disposable Firecracker VMs. Each scope has its own Forgejo runner UUID/token, and neither should require an instance-level runner registration.

Our deployed NixOS configuration uses Rith revision 80c7179240dcf28afe00337bedfe94a8bb744ffc and exposes a single services.unified-ci.forgejo registration. We want to attach both registrations to the existing host while keeping its total concurrency at three jobs. Running separate controllers would require manually partitioning capacity and maintaining separate services.

Requested behavior

Support multiple named Forgejo registrations in a single controller, with corresponding NixOS module options:

Separate instance URL, runner identity, labels/template selection, and credentials path for each registration. Credentials should remain compatible with Agenix-managed files.
One shared scheduler and global concurrency, CPU, memory, and disk admission budgets across all registrations. Two registrations must not each admit three jobs when the host-wide limit is three.
Fair polling/admission so a busy personal account cannot indefinitely starve organization jobs, or vice versa.
Registration-scoped task identities: task IDs can overlap across Forgejo instances, so job IDs, claim journals, delivery retries, log archives, and restart recovery must remain unambiguous.
Independent authentication and polling failures, with status and diagnostics identifying the affected registration without exposing credentials.
Credentials and task/log publication must stay bound to the originating registration. Job VMs must not receive other registrations' controller credentials.
Preserve existing single-registration configuration compatibility.

Acceptance criteria

With personal and organization registrations configured, both appear online in Forgejo and can execute jobs through the same controller. Queuing jobs in both scopes never exceeds the global three-job limit. Restart recovery and log publication use the correct registration, and one registration's invalid credentials do not prevent the other from processing work.

Include scheduler/recovery tests for multiple registrations, including overlapping task IDs, and a documented NixOS configuration example. Disposable Firecracker VMs should continue to require no individual Forgejo registration.

## Use case Run CI for both a personal account and an organization on the same Forgejo instance using one Rith controller and one pool of disposable Firecracker VMs. Each scope has its own Forgejo runner UUID/token, and neither should require an instance-level runner registration. Our deployed NixOS configuration uses Rith revision `80c7179240dcf28afe00337bedfe94a8bb744ffc` and exposes a single `services.unified-ci.forgejo` registration. We want to attach both registrations to the existing host while keeping its total concurrency at three jobs. Running separate controllers would require manually partitioning capacity and maintaining separate services. ## Requested behavior Support multiple named Forgejo registrations in a single controller, with corresponding NixOS module options: - Separate instance URL, runner identity, labels/template selection, and credentials path for each registration. Credentials should remain compatible with Agenix-managed files. - One shared scheduler and global concurrency, CPU, memory, and disk admission budgets across all registrations. Two registrations must not each admit three jobs when the host-wide limit is three. - Fair polling/admission so a busy personal account cannot indefinitely starve organization jobs, or vice versa. - Registration-scoped task identities: task IDs can overlap across Forgejo instances, so job IDs, claim journals, delivery retries, log archives, and restart recovery must remain unambiguous. - Independent authentication and polling failures, with status and diagnostics identifying the affected registration without exposing credentials. - Credentials and task/log publication must stay bound to the originating registration. Job VMs must not receive other registrations' controller credentials. - Preserve existing single-registration configuration compatibility. ## Acceptance criteria With personal and organization registrations configured, both appear online in Forgejo and can execute jobs through the same controller. Queuing jobs in both scopes never exceeds the global three-job limit. Restart recovery and log publication use the correct registration, and one registration's invalid credentials do not prevent the other from processing work. Include scheduler/recovery tests for multiple registrations, including overlapping task IDs, and a documented NixOS configuration example. Disposable Firecracker VMs should continue to require no individual Forgejo registration.

thesimplekid referenced this issue from a commit

2026-10-21 04:04:34 +00:00

feat: support multiple Forgejo runner registrations

thesimplekid referenced this issue from a pull request that will close it,

2026-10-21 04:05:09 +00:00

feat: support multiple Forgejo runner registrations #11

thesimplekid closed this issue

2026-10-22 17:38:32 +00:00