You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> This is a documentation about a unreleased version of actions-runner-controller.
329
-
>
330
-
> It would be great if you could try building the latest controller image following https://github.com/actions-runner-controller/actions-runner-controller#contributing if you are eager to test it early and help
331
-
> developers by reporting any bugs :smile:
329
+
> This feature is available since actions-runner-controller v0.19.0
332
330
333
331
You can either delete the runner deployment, or update it to have `replicas: 0`, so that there will be 0 runner pods in the cluster. This, in combination with e.g. `cluster-autoscaler`, enables you to save your infrastructure cost when there's no need to run Actions jobs.
334
332
@@ -599,10 +597,7 @@ See ["activity types"](https://docs.github.com/en/actions/reference/events-that-
599
597
600
598
#### Autoscaling to/from 0
601
599
602
-
> This is a documentation about a unreleased version of actions-runner-controller.
603
-
>
604
-
> It would be great if you could try building the latest controller image following https://github.com/actions-runner-controller/actions-runner-controller#contributing if you are eager to test it early and help
605
-
> developers by reporting any bugs :smile:
600
+
> This feature is available since actions-runner-controller v0.19.0
606
601
607
602
Previously, we've discussed about [how to scale a RunnerDeployment to/from 0](#note-on-scaling-tofrom-0)
608
603
@@ -624,10 +619,7 @@ Similarly, Webhook-based autoscaling works regardless of there are active runner
624
619
625
620
#### Scheduled Overrides
626
621
627
-
> This is a documentation about a unreleased version of actions-runner-controller.
628
-
>
629
-
> It would be great if you could try building the latest controller image following https://github.com/actions-runner-controller/actions-runner-controller#contributing if you are eager to test it early and help
630
-
> developers by reporting any bugs :smile:
622
+
> This feature is available since actions-runner-controller v0.19.0
631
623
632
624
`Scheduled Overrides`allows you to configure HorizontalRunnerAutoscaler so that its Spec gets updated only during a certain period of time.
633
625
@@ -936,6 +928,98 @@ Note that there's no official Istio integration in actions-runner-controller. It
> This is a documentation about a unreleased version of actions-runner-controller.
934
+
>
935
+
> It would be great if you could try building the latest controller image following https://github.com/actions-runner-controller/actions-runner-controller#contributing if you are eager to test it early and help
936
+
> developers by reporting any bugs :smile:
937
+
938
+
`actions-runner-controller`supports `RunnerSet` API that let you deploy stateful runners. A stateful runner is designed to be able to store some data persists across GitHub Actions workflow and job runs. You might find it useful, for example, to speed up your docker builds by persisting the docker layer cache.
939
+
940
+
A basic `RunnerSet` would look like this:
941
+
942
+
```
943
+
apiVersion: actions.summerwind.dev/v1alpha1
944
+
kind: RunnerSet
945
+
metadata:
946
+
name: example
947
+
spec:
948
+
ephemeral: false
949
+
replicas: 2
950
+
repository: mumoshu/actions-runner-controller-ci
951
+
# Other mandatory fields from StatefulSet
952
+
selector:
953
+
matchLabels:
954
+
app: example
955
+
serviceName: example
956
+
template:
957
+
metadata:
958
+
labels:
959
+
app: example
960
+
```
961
+
962
+
As it is based on `StatefulSet`, `selector` and `template.medatada.labels` needs to be defined and haev the exact same set of labels. `serviceName` must be set to some non-empty string as it is also required by `StatefulSet`.
963
+
964
+
Runner-related fields like `ephemeral`, `repository`, `organiåtion`, `enterprise`, and so on should be written directly under `spec`.
965
+
966
+
Fields like `volumeClaimTemplates` that originates from `StatefulSet` shuold also be written directly under `spec`.
967
+
968
+
Pod-related fields like security contexts and volumes are written under `spec.template.spec` like `StatefulSet`.
969
+
970
+
Simillarly, container-related fields like resource requests and limits, container image names and tags, security context, and so on are written under `spec.template.spec.containers`. There are two reserved container `name`, `runner` and `docker`. The former is for the container that runs [actions runner](https://github.com/actions/runner) and the latter is for the container that runs a dockerd.
971
+
972
+
For a more complex example, see the below:
973
+
974
+
```
975
+
apiVersion: actions.summerwind.dev/v1alpha1
976
+
kind: RunnerSet
977
+
metadata:
978
+
name: example
979
+
spec:
980
+
# NOTE: RunnerSet supports non-ephemeral runners only today
981
+
ephemeral: false
982
+
replicas: 2
983
+
repository: mumoshu/actions-runner-controller-ci
984
+
dockerdWithinRunnerContainer: true
985
+
template:
986
+
spec:
987
+
securityContext:
988
+
#All level/role/type/user values will vary based on your SELinux policies.
989
+
#See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/docker_selinux_security_policy for information about SELinux with containers
990
+
seLinuxOptions:
991
+
level: "s0"
992
+
role: "system_r"
993
+
type: "super_t"
994
+
user: "system_u"
995
+
containers:
996
+
- name: runner
997
+
env: []
998
+
resources:
999
+
limits:
1000
+
cpu: "4.0"
1001
+
memory: "8Gi"
1002
+
requests:
1003
+
cpu: "2.0"
1004
+
memory: "4Gi"
1005
+
- name: docker
1006
+
resources:
1007
+
limits:
1008
+
cpu: "4.0"
1009
+
memory: "8Gi"
1010
+
requests:
1011
+
cpu: "2.0"
1012
+
memory: "4Gi"
1013
+
```
1014
+
1015
+
You can also read the design and usage documentation written in the original pull request that introduced `RunnerSet` for more information.
Under the hood, `RunnerSet` relies on Kubernetes's `StatefulSet` and Mutating Webhook. A statefulset is used to create a number of pods that has stable names and dynamically provisioned persistent volumes, so that each statefulset-managed pod gets the same persisntet volume even after restarting. A mutating webhook is used to dynamically inject a runner's "registration token" which is used to call GitHub's "Create Runner" API.
1020
+
1021
+
We envision that `RunnerSet` will eventually replaces `RunnerDeployment`, as `RunnerSet` provides a more standard API that is easy to learn and use because it is based on `StatefulSet`, and it has a support for `volumeClaimTemplates` which is crucial to manage dynamically provisioned persistent volumes.
0 commit comments