Nikola JokicandCopilot App
2877779b72
The scaler issued every API call a message asked for before returning, and the listener acks only once it returns. A full batch of job started events is 50 of them, two calls each, so the next scale decision sat behind 100 calls of bookkeeping. Those patches are not what new jobs wait on. Only the desired runner count creates runners; Status.JobID is a hint the runner set consults when choosing which idle runner to delete, and the Actions service rejects the deletion of a runner whose job is still running either way. Publish the desired count first, hand the job started events to a background pool, and acquire after. Acquiring last costs the round trip of the scale patch and saves the whole batch, and the scale decision is unaffected: it comes from msg.Statistics, a snapshot the service took when it built the message, so jobs acquired now are reported as assigned in a later one. Give the two kinds of traffic their own clients. Sharing one token bucket is what let the job patches delay the scale patch, so splitting them is what makes the reordering worth anything; backgrounding alone would just move the same queue. Measured against a 5ms API server and a 50ms Actions service, at a full 50 event batch: scale patch reaches the API server 1.971s -> 6ms listener loop 2.02s -> 107ms/msg The loop no longer spends the rate limit inline, so its cost is now the two service round trips rather than the batch size. This does not raise throughput. Job patches still cost two calls per event, so the job client sustains qps/2 job starts per second, and the queue is bounded by the real job start rate rather than by how fast the listener polls: a faster loop polls more often and carries proportionally fewer events. Measured at qps 40, the queue stays empty through 18 starts/sec and degrades gradually past 20 rather than falling over. Close drains the queue, since the message these patches came from was acked long before they run. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Actions Runner Controller (ARC)
About
Actions Runner Controller (ARC) is a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions.
With ARC, you can create runner scale sets that automatically scale based on the number of workflows running in your repository, organization, or enterprise. Because controlled runners can be ephemeral and based on containers, new runner instances can scale up or down rapidly and cleanly. For more information about autoscaling, see "Autoscaling with self-hosted runners."
You can set up ARC on Kubernetes using Helm, then create and run a workflow that uses runner scale sets. For more information about runner scale sets, see "Deploying runner scale sets with Actions Runner Controller."
People
Actions Runner Controller (ARC) is an open-source project currently developed and maintained in collaboration with the GitHub Actions team, external maintainers @mumoshu and @toast-gear, various contributors, and the awesome community.
If you think the project is awesome and is adding value to your business, please consider directly sponsoring community maintainers and individual contributors via GitHub Sponsors.
If you are already the employer of one of the contributors, sponsoring via GitHub Sponsors might not be an option. Just support them by other means!
See the sponsorship dashboard for the former and the current sponsors.
Getting Started
To give ARC a try with just a handful of commands, please refer to the Quickstart guide.
For an overview of ARC, please refer to About ARC.
With the introduction of autoscaling runner scale sets, the existing autoscaling modes are now legacy. The legacy modes have certain use cases and will continue to be maintained by the community only.
For further information on what is supported by GitHub and what's managed by the community, please refer to this announcement discussion.
Documentation
ARC documentation is available on docs.github.com.
Legacy documentation
The following documentation is for the legacy autoscaling modes that continue to be maintained by the community:
- Quickstart guide
- About ARC
- Installing ARC
- Authenticating to the GitHub API
- Deploying ARC runners
- Adding ARC runners to a repository, organization, or enterprise
- Automatically scaling runners
- Using custom volumes
- Using ARC runners in a workflow
- Managing access with runner groups
- Configuring Windows runners
- Using ARC across organizations
- Using entrypoint features
- Deploying alternative runners
- Monitoring and troubleshooting
Contributing
We welcome contributions from the community. For more details on contributing to the project (including requirements), please refer to "Getting Started with Contributing."
Troubleshooting
We are very happy to help you with any issues you have. Please refer to the "Troubleshooting" section for common issues.