Set up Gitea Actions Runner


Set up Gitea Actions Runner

Background

Some years ago I set up a homelab server where I host applications of all kinds. The server has been a media server with Plex and Jellyfin, but lately I wanted to use it as a CI/CD server for my git projects.

After some thought I landed on Gitea, as it is a git server with the functionality I want. Because I wanted to set up CI/CD I needed a place to store the container images, and since Gitea comes with a builtin container registry it made the choice easier.

I could have chosen other git servers and set up a Container registry like Project Quay, but I wanted an all-in-one solution for now.

Gitea

The Gitea setup was quite straight forward, and with some configuration I managed to integrate my Keycloak server as an OIDC provider. I haven’t set up SSH access, but I may want to do it in the future.

After Gitea was set up, I wanted to add CI/CD functionality and add a build agent.

Gitea build agent

Adding the build agent was straight forwards. Add a container with some configuration and a registration token, and you’re ready to go.

There are some minor snags to keep in mind, though.

1. Labels determine how the agent functions.

If a label does not refer to a container image, the actions are run inside the action runner container. This may be preferable in some cases, but some actions require node to be installed. If node is not present, you’ll be unable to clone the repository.

2. The Docker Socket

The docker socket is necessary for communicating with the Docker compatible host. This may be CRI-O, Docker, Podman or any other CRI-O compatible host.

My setup uses rootless Podman to keep the containers isolated from the rest of the machine, which should make it difficult to much harm if anyone should be able to escape the container.

When configuring the Gitea Build Agent it is recommended to mount the Docker socket in the container, and when I figured out the labels, it seemed that the agent was running as it should. It should be mentioned that the build agent used the default configuration to start with.

When I was about to try a build, I noticed that act_runner container was downloading; then suddenly the build failed with the following message:

time=“2023-03-15T20:52:03Z” level=error msg=“execute task: failed to create container: ‘Error response from daemon: container create: statfs /var/run/docker.sock: permission denied’” func=Poll

The message left me somewhat dumbfounded as I didn’t understand why I got this error when the image had downloaded correctly.

After some trial and error, and playing around with the act_runner configuration file, I found the reason. The act_runner container tries to mount /var/run/docker.sock in the “ubuntu-latest” build container. Because my system is set up the way it is, this file does not exist on my host.

Because I use rootless Podman the correct socket location is /var/run/user/1000/podman/podman.sock, which is the socket I’ve mounted in the Gitea act_runner container.