Limiting the Number of Runners per Repository

What would you like added?

I would like to request the addition of a feature that allows for limiting the number of GitHub Actions runners that can be concurrently utilized by a single repository. This feature is necessary to address resource allocation challenges in scenarios where certain repositories require a high number of concurrent jobs, potentially occupying all available runners and leaving no resources for other repositories.

Why is this needed?

The current behavior of the GitHub Actions Runner Controller does not provide a built-in mechanism to control the number of runners per repository. This leads to situations where repositories with high job concurrency can exhaust all available runners, causing resource shortages for other repositories. By introducing the ability to set a maximum limit, resource allocation can be more balanced and ensure fair access to runners across repositories.

Additional context

In our setup, we manage and scale our runners between 2 and 10 instances. However, certain repositories require a significantly higher number of concurrent jobs, sometimes reaching up to 30 jobs. This results in a skewed distribution of resources, where a single repository occupies all available runners, leaving other repositories without access to runners. To distribute resources more evenly, we are looking for a feature that allows us to impose a limit, such as 5 runners per repository. Although GitHub may not offer a built-in feature for this, we are open to suggestions or alternative methods to achieve this runner limitation per repository.

Your assistance and guidance in implementing this feature would be greatly appreciated. Thank you!

Start by reviewing how the controller currently scales and allocates runners for repositories, then determine where a per-repository maximum could be configured and enforced. Done means supporting a limit such as five concurrently used runners per repository while preserving access for other repositories; the issue names no files or tests, so the implementation entry point must first be located.