Nikola JokicandCopilot App
8148c24c37
Scale used to hold the replica patch back whenever the target dropped, so that every job started patch had landed before the runner set controller could act on a lower count. The reasoning was that deleteIdleEphemeralRunners skips a runner only once it carries a job ID, so a runner that had just picked up a job could otherwise be deleted. That guard was unreachable. The controller only deletes idle runners under Spec.PatchID == 0, and setDesiredWorkerState emits patch ID 0 only when the target is unchanged and equal to MinRunners, or on the very first patch, when no previous target exists. Neither can coincide with a falling target, so a scale down never reaches the deletion path. Exhaustively walking message sequences over every MinRunners/MaxRunners pair finds no state where the two occur together. So the replica patch has no reason to wait, and good reason to go first: it is the only patch that creates runners, and therefore the one new jobs wait on, while the job event patches are bookkeeping the controller reads later. Sending it first also keeps it clear of the client rate limiter, which a large batch of event patches would otherwise drain ahead of it. The job events still have to land before Scale returns. The listener acks the message the moment it does, and nothing other than these patches ever writes Status.JobID, so a patch dropped after the ack would leave a busy runner looking idle to the scale down that a later patch ID 0 permits. 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.