IssueOps example on how to set up an autoscaling, self-hosted runner fleet in kubernetes using summerwind/actions-runner-controller.
Watch a three minute demo to see what this project can do for you.
In order to setup or modify an auto-scaling runner set, just create an issue:
and /approve the Kubernetes config changes in the resulting pull request:
The resulting pull request also contains a workflow file snippet to test your newly created runner group:
In order to use your own Docker runner images, follow the suggestions here. The Dockerfile used to produce the default image for the issue template has been checked into this repository.
If you like to work directly with this repository, there is no further need but to follow the comments in the issues created by the template and the approved PR.
If you like to setup a copy of this repository somewhere else, you would need to install the actions-runner controller in a Kubernetes cluster as described here.
While most code in this IssueOps example has been written to be cloud agnostic, the part to authenticate to the cluster is currently specific to GCP. If you are also using GCP, set the following GitHub Action credentials to authenticate to the cluster:
- CLUSTER_LOCATION: GCP cluster location where you setup the actions-runner controller
- CLUSTER_NAME: GCP cluster name
- GCP_SA_KEY: GCP service account with permissions to create new namespaces and objects within
- PROJECT_ID: GCP project id of your cluster
If you are using a different cloud, you would only need to adjust the steps needed to get to the point where your runner can successfully execute kubectl commands - pull requests are welcome 
❤️
Last but not least, you would need to create two labels in the copy of this repository: self-hosted-runner-scale-set and delete-self-hosted-runner-scale-set