Last Monday, Christoph Lipautz presented a custom GitLab Runner executer that is using podman under the hood at our monthly Go meetup in Graz: Pogo. The executor is the component in the GitLab CI system that actually runs jobs passed to it. For that it handles 4 life-cycle steps: (1) config, (2) prepare, (3) run, and finally (4) cleanup . The runner provided by GitLab for use in your own environment comes with the following executors:
If you want to have something different, then you have to hook a so-called custom executor which is what Pogo now provides. In general, the solution provides pretty much the same level of abstraction as the Docker executor but does not require a service running as root. Especially for on-premise systems this might be quite interesting and you cannot simply provision and de-provision machines that easily but also don’t have to fear a job somehow gaining root access due to an issue within Docker.
Another nice feature of Pogo is that you can define custom volumes that should be mounted into the job’s execution environment depending on what tags are set for the job. Let’s say that you have a job tagged with
data-media then you could automatically mount a
media folder into the job using the following configuration of the executor itself:
mounts: - volume: "/mount/shared-media:/mount/media" tags: - "data-media"
I’ve been thinking again and again about moving my repositories off of GitHub and over to GitLab again. When (not if) I finally decided to do that and once again use my own runners, then I’ll definitely take a look at Pogo! But first I should probably finally spend some time with podman, nerdctl and all the other non-Docker container stuff that is available on Linux 😅
Do you want to give me feedback about this article in private? Please send it to firstname.lastname@example.org.
Alternatively, this website also supports Webmentions. If you write a post on a blog that supports this technique, I should get notified about your link 🙂