Gitea actions in Kubernetes

I spend a few weeks of scarce free time trying to make gitea run in k8s with CI using Gitea Actions. Here's me detailing how.

Published 27. August 2024

I am a strong believer in not depending too much on others for things that matter. I am also an engineer who likes to tinker and learn new stuff. Therefore, I thoughgt it was a good idea to try hosting my own gitea instance. One of the big selling points was the fact that gitea has most features I wanted from gitlab, without being a huge pain in the ass to install and manage in k8s. Too bad it still deploys using Helm.

However, I found getting gitea actions (the now inbuilt CI platform, based on the ACT runner) working, hard. It seems straight forward, two examples are given: one using dind, and one using rootless docker: https://gitea.com/gitea/act_runner/src/branch/main/examples/kubernetes. I have bad experience with rootless docker when it comes to dealing with permissions inside and outside of the container, so I settled on dind for now. I ran their test action, and everything worked well. Yay! The next step was trying to get a Docker container built, and this is where the problems started. I was unable to get anything inside the CI job to talk to a Docker daemon.

Searching around on the internet it seems many have had problems with ACT and kubernetes, but most of the problems have been with getting ACT to talk to dind/rootless docker, not with getting something on the inside of a CI job to talk to the Docker daemon. I tried a lot of suggested unix socket paths from stackoverflow posts, hoping someone had misunderstood some documentation that was really about how to get docker from inside a job talking to a docker daemon:

unix:///var/run/docker.sock
unix:///var/run/user/0/docker.sock
unix:///var/run/user/1000/docker.sock

I also tried running find in a CI job to find any possible docker sockets. Last, i tried the TCP URIs tcp://localhost:2376 and tcp://docker:2376. As port 2376 was the one exposed by my dind daemon, it would make sense that had the CI runner been configured correctly and the intent was to access docker through TCP, this would have been correct. However, it wasn't. The situation seemed to be that there was no way for the CI job to access the Docker daemon.

Thankfully, after asking around on the Gitea Discord server, someone pointed me in the direction of this gist. While it is slightly cargo culty in nature to simply copy-paste it blindly, after reading the gist, it had some CLI arguments that seemed like they could solve the problem I was having: --add-host=docker:host-gateway -v /certs:/certs. I set up a configuration file for my gitea ACT runner with the aforementioned CLI options, pointed my in-CI docker to tcp://docker:2376, and bam - it worked. lreading's suggestion of setting additional environment variables for jobs that autoconfigure docker with the correct daemon host was also very welcome.

I am posting about the experience so others that are struggling with the same issue have a chance of solving it. Discord is a horrible choice for any kind of community information database, after all.

What i still don't know

It seems Gitea ACT is a very fresh feature, and even gitea engineers don't seem to have made up their mind on how it is supposed to be deployed in k8s, so there's probably more information to come.