Nikola JokicandCopilot App b3e44a1c39 Filter owned-resource events in the workqueue
Every controller in this package woke up on every update of the resources it
owns, including the ones that only touch fields it never reads. An
EphemeralRunner status carries readiness, failure bookkeeping and the job
details written by the listener, a pod reports IPs, its node, a start time and
several conditions, and an EphemeralRunnerSet rewrites
Status.FinishedRunnerCleanupPatchID for every listener patch id. None of that is
input to the owner, yet all of it enqueued a reconcile.

Add an update predicate to each owned watch. A predicate is only allowed to be
an optimisation, so each one is written as the projection of the fields its
reconciler actually reads and drops an update only when all of them are equal:

  - AutoscalingRunnerSet -> EphemeralRunnerSet: object metadata, the whole spec,
    and the Status.Phase and Status.AppliedActionableRevision pair that
    ephemeralRunnerSetOutdatedForAppliedRevision consults.
  - EphemeralRunnerSet -> EphemeralRunner: object metadata, spec, Status.Phase
    and Status.RunnerID.
  - EphemeralRunner -> Pod: UID, deletion timestamp, pod phase, reason and
    message, the container and init container statuses, and the Ready
    condition.

An event of an unexpected type is always delivered, and create, delete and
generic events are untouched. The primary watches keep seeing every update, so
the status patches a reconciler makes to hand work to its own next pass, such
as marking a runner Failed or Outdated before cleaning up its resources, still
re-enqueue.

The Ready condition lookup is extracted into podReady so that the predicate and
updateRunStatusFromPod cannot disagree about what readiness means.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-09-11 11:37:23 +02:00
2026-09-10 22:56:48 +02:00
2026-05-22 12:07:13 +02:00
2023-05-28 16:36:55 +09:00
2026-08-31 16:53:02 +01:00
2024-06-21 12:11:29 +02:00
2022-12-13 11:38:01 +00:00
2026-05-22 12:04:06 +02:00
…
2026-08-31 16:53:02 +01:00
2022-12-13 11:39:39 +00:00

Actions Runner Controller (ARC)

CII Best Practices awesome-runners Artifact Hub

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:

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.

S
Description
No description provided
Readme
52 MiB
Languages
Go 83.7%
Shell 6.5%
Smarty 5.4%
Dockerfile 2.5%
Makefile 1.6%
Other 0.3%