GitHub Actions Kubernetes Runner

Some time ago I had the Idea to build an GitHub Actions Runner which runs on Kubernetes.
Basically I wanted to build a Runner which works a bit like the GitLab K8s Runner, basically the following:

  • Containerized Agent
  • Deployment via Helm Chart
  • For each Job a Pod gets scheduled

The biggest Issue currently is the GitHub Actions API isn’t nowhere documented or not event public? So currently it is really hard to start building such Runner.
Are there any plans on creating a Documentation for the GitHub Actions API or even plans for building such runner which I described?
Thanks!

2 Likes

Thanks for your feedback.
Normally we install self-hosted runner according to the following steps:

  1. Create a folder under the drive root, Download the latest runner package and Extract the installer. Such as:
// Create a folder under the drive root
$ mkdir actions-runner; cd actions-runner 
// Download the latest runner package
$ Invoke-WebRequest -Uri https://github.com/actions/runner/releases/download/v2.273.0/actions-runner-win-x64-2.273.0.zip -OutFile actions-runner-win-x64-2.273.0.zip 
// Extract the installer
$ Add-Type -AssemblyName System.IO.Compression.FileSystem ; [System.IO.Compression.ZipFile]::ExtractToDirectory("$PWD/actions-runner-win-x64-2.273.0.zip", "$PWD")
  1. Use this API to create a registration token for an organization.
  2. Create the runner and start the configuration experience with the registration token from step2 and then run the Agent. Such as:
// Create the runner and start the configuration experience
$ ./config.cmd --url https://github.com/{Your organization}/{Your project} --token {Your token} 
// Run it!
$ ./run.cmd

By the way, there is an existing repo here that may be related to your needs, please check it and hope it helps.

Hi @niconbw! Thanks for your feedback.

Let me provide you with some more details. Our main idea was to achieve the following:

  1. A containerized & self-hosted GitHub Action Runner on Kubernetes. Basically what the kubeact does.
  2. Instead of running the job inside the Action Runner Pod, we thought about a Runner that is aware of Kubernetes and schedules Pod based on a defined Container image. Basically what Azure DevOps does with Container Jobs but as Pods.

A good example of this is the GitLab Runner Kubernetes Executor.

Our idea was to build such a runner, but due to missing documentation of the API, we aren’t able to do so. The API documentation only includes how to register a runner. Nothing further.

1 Like

Hi @nmeisenzahl
I did not find further API as you said. I recommend that you can directly report your requests here. That will allow you to directly interact with the appropriate engineering team, and make it more convenient for the engineering team to collect and categorize your idea. Thanks

Hi @niconbw! Thanks for the hint! I will contact them.

/cc @StiviiK

Hello world! :wave:

I’m actively working on helm charts to deploy, configure and run containerized actions-runner's in a Kubernetes cluster along with a (optional, by default enabled) docker in docker deployment configured with the actions-runner for using docker and docker-compose in job runs. Is wip / beta at the moment: https://github.com/lazybit-ch/actions-runner

# GitHub Packages login to pull images
kubectl create secret docker-registry docker-0 \
    --docker-username=${DOCKER_USERNAME} \
    --docker-password=${DOCKER_PASSWORD} \
    --docker-server=ghcr.io
helm repo add lazybit https://chartmuseum.lazybit.ch
helm repo update
# Github Token to checkout the repository
helm install actions-runner \
    --set global.image.pullSecrets[0]=docker-0 \
    --set github.username=${GITHUB_USERNAME} \
    --set github.password=${GITHUB_TOKEN} \
    --set github.owner=my-org \
    --set github.repository=my-repo \
    --set dind.enabled=false \
    lazybit/actions-runner

I use kind=v0.9.0 for dev and pushed a kind.sh to the dev branch if anyone wants to hack at it. Can:

  • build images with kaniko in docker
  • use kubectl with rbac to create pods (i.e. use kaniko in a kubectl run)
  • use docker and docker-compose (all the things docker!)

I push latest tags for both of the images to Github Container Registry and GitHub Packages. Charts are pushed to a hosted ChartMuseum instance with anon pull enabled for the moment. Working on a blog post or five as well (need longer days). Update: I’ve added a short blog post https://blog.lazybit.ch/github-actions-runners-self-hosted-in-kubernetes/ with more details.