Autoscaling for an organization runner

[jeffj254]

I'm experimenting with self-hosted runners on Kubernetes. I'm trying to setup an auto-scaled runner deployment for an entire org in GitHub. While I can specify the org in the RunnerDeployment config, it seems like I'm only able to have this deployment scale by listing specific repos in repositoryNames in the HorizontalRunnerAutoscaler to watch for the number of pending workflows. Is there any way to scale based on all workflows across an entire org?

It doesn't look like the Actions API currently has a "list runs for organization" endpoint, so maybe that answers my question, but I figured I'd ask in case I was missing something.

[Warashi]

List organization repositories API can solve this issue?
https://developer.github.com/v3/repos/#list-organization-repositories

[ghost]

https://docs.github.com/en/free-pro-team@latest/rest/reference/actions#list-selected-repositories-enabled-for-github-actions-in-an-organization this would work too if youre not on GHE.

[mumoshu]

Thank you so much for your efforts on #213 @erikkn!
It took too much time wrapping my head around this issue.

TL;DR; I think we have a possible solution to this now. Try using PercentageRunnersBusy.

Today, we have two scaling strategies TotalNumberOfQueuedAndInProgressWorkflowRuns and PercentageRunnersBusy. The former required #213. The latter seems to work on any kind of runner.

The only known downside of PercentageRunnersBusy is that depending on the configuration it takes a bit more time to scale runners out on demand. The workaround is to tweak scaleUpThreshold and scaleUpFactor so that it becomes less chances to workflow runs occupy all the runners.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mumoshu]

@Warashi BTW, the List Organizations API solves only part of the problem. You can definitely fix it to not force us to list all the repos under repositoryNames, but you still need to figure out which repository name the RunnerDeployment is supposed to be used. Otherwise the controller would end up scaling the RunnerDeployment on queue/in progress workflow runs in irrelevant repos (like you end up scaling selfhosted runners on runs queued on repos that uses only managed runners

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ajitkumarnayak1976]

There are 2 ways to achieve Horizontal Autoclavability on Ephemeral Runner.

Pull Driven Scaling - The Scale in and out is based on Metrics attribute. The Metrics could be of TotalNumberOfQueuedAndInProgressWorkflowRuns or PercentageRunnersBusy
Webbook Driven Scaling - The webbook server receives GitHub Webbook events and scales RunnerDeployments by updating corresponding HorizontalRunnerAutoscalers. the Webhook server can be configured to respond to GitHub's check_run, workflow_job, pull_request, and push events by scaling up the matching HorizontalRunnerAutoscaler by N replica(s), where N is configurable within HorizontalRunnerAutoscaler's spec:. Webbooks are processed by a separate webhook server.

But what would be the best recommended approach and why ?