actions-runner-controller VS ghat

To set-up the self-hosted runner, an Action Runner Controller (ARC) and Runner scale sets application will be installed via helm. This post will be using Azure Kubernetes Service and ARC that is officialy maintained by Github. There is another ARC that is maintained by the community. You can follow the discussion where github adopted the ARC project into a full Github product here

Before this we were using https://github.com/actions/actions-runner-controller but that's running on K8s instead of VMs. So along with common limitations of running CI jos in K8s/container, it cannot have exactly the same environment as the official GitHub runners. Maintaining a K8s cluster was also very difficult.

ARC is great for running GitHub Actions on Kubernetes:

https://github.com/actions/actions-runner-controller

There are also official Heml charts available for ARC: https://github.com/actions/actions-runner-controller

I am in the process of setting it up on a cheap Hetzner box. If it works, would be a great deal! You can get a 64 GB RAM box for 35 EUR/mo at server auctions with unlimited traffic. I don't mention CPU or GPU, as typically this isn't a bottleneck for my projects.

Plus, I can configure cache sharing via host-mounted dir. E.g. pnpm cache can be all in one place, and be locally available to pods via a mounted dir. Same for the Docker image cache. This would speed up CI runs and also reduce network traffic by a huge margin.

GitHub Actions effectively has no local caching. There's an action for caching, but it uses a blob storage for cache artifacts. Which then gets network fetched, gzip'ed and gunzip'ed each time, and from my experience this has never been a gain for medium to large npm projects, as they have thousands of small .js files in node_modules, and thus takes a long time to compress and decompress. I think npm edge cache servers are already so optimized and fast, that in my experience almost always it's faster to install from npm directly. I even tested this on AWS, where the cache was stored in S3, in the same region as CodeBuild (CI), and direct installs from npm were still faster by about 30%.

So other than adding more hardware resources, local caching is the only way to significantly speed up GH Actions, from my experience, and thus you must have your runner.

Older bugs show setting of enterprise URL ( kubectl set env deploy actions-runner-controller -c manager GITHUB_ENTERPRISE_URL=https:// --namespace actions-runner-system) with and values.yml also shows githubEnterpriseServerURL (https://github.com/actions/actions-runner-controller/blob/master/charts/actions-runner-controller/README.md ).

You need to use the steps in the repo instead of the steps on the docs if you're using enterprise server.

GitHub has made it possible to run GitHub Actions using your own self-hosted runners. Thanks to the Actions Runner Controller it is surprisingly easy to run actions in your Kubernetes clusters.

Since GitHub official has not provided to deploy a Self-hosted runner on Kubernetes, I used the Actions Runner Controller (ARC) project, This project allows rapid deployment of Self-hosted runners through Runner custom resources.

K8s Controller: Kubernetes controller for GitHub Actions self-hosted runner

View on GitHub

3.5 I was excited to see action composition until I realized that the composed action will still be showed as one step and that it can just compose actions instead of whole workflows.

I want to share whole jobs across my repos, including matrixes and all. I could wrap some common workflows into one action, but then the whole complexity will be hidden in a single step.

So I resorted to creating GHA Templates and manually synching them with a CLI tool: https://github.com/fregante/ghat