3.1 KiB
actions-runner-controller v0.25.0
All planned changes in this release can be found in the milestone https://github.com/actions/actions-runner-controller/milestone/8.
Also see https://github.com/actions/actions-runner-controller/compare/v0.24.1...v0.25.0 for full changelog.
This log documents breaking changes and major enhancements
Upgrading
In case you're using our Helm chart to deploy ARC, use the chart 0.20.0 or greater. Don't miss upgrading CRDs as usual! Helm doesn't upgrade CRDs.
BREAKING CHANGE : Support for --once has been dropped
In case you're still on ARC v0.23.0 or earlier, please also read the relevant part of v0.24.0 release note for more information.
Relevant PR(s): #1580, #1590
ENHANCEMENT : Support for the new Kubernetes container mode of Actions runner
The GitHub Actions team has recently added actions/runner an ability to use runner container hooks to run job steps on Kubernetes pods instead of docker containers created by the docker command. It allows us to avoid the use of privileged containers while still being able to run container-backed job steps.
To use the new container mode, you set .spec.template.spec.containerMode in RunnerDeployment to "kubernetes", while defining .spec.template.spec.workVolumeClaimTemplate. The volume claim template is used for provisioning and assigning persistent volumes mounted across the runner pod and the job pods for sharing the job workspace.
Before using this feature, we highly recommend you to read the detailed explanation in the original pull request, and the new section in ARC's documentation.
Big kudos to @thboop and the GitHub Actions team for implementing and contributing this feature!
Relevant PR(s): #1546
FIX : Webhook-based scaling is even more reliable
We fixed a race condition in the webhook-based autoscaler that resulted in not adding a runner when necessary.
The race condition had been happening when it received a webhook event while processing another webhook event and both ended up scaling up the same horizontal runner autoscaler at the same time.
To mitigate that, ARC now uses Kubernetes' Update API instead of Patch to update HRA.spec.capacityReservations which is the underlying data structure that makes the webhook-based scaler to add replicas to RunnerDeployment or RunnerSet on demand.
We were also worried about stressing the Kubernetes apiserver when your ARC webhook-based autoscaler received a lot of concurrent webhook events, we also enhanced it to batch the Update API calls for 3 seconds, which basically means it will call the Update API at most once every 3 seconds per webhook-based autoscaler instance.
Lastly, we fixed a bug in the autoscaler that resulted in it to stop adding replicas for newly received webhook events when the desired replicas reached maxReplicas.
Relevant PR(s): #1477, #1568