On 4/19/23 10:42, jklaiho(a)iki.fi wrote:
Assuming that GitLab Runner supports ssh:// socket addresses
Since nobody else responded, I'll take a guess: Given how
docker-centric github-actions are, I'm going to suggest challenging this
assumption. Mainly because doing your second idea (making the machine
socket available) is fantastically more complex.
Support for `unix` and `http/https` schemes would be fairly trivial to
implement. However, the `ssh` scheme is decidedly more complex (i.e.
dealing with known_hosts, choosing keys, etc). Given how Docker-centric
github-actions are, I'm guessing they haven't done it.
Though I could be completely wrong. So I'd suggest digging into the
github-runner documentation first. If not that, perhaps there's a
discussion board you could post on.
I'd like to operate Podman rootlessly for this purpose
Doing this rootless isn't going to be a challenge. Making the socket
accessible is the "real" challenge here.
I vaguely recall there's a way to serve up a unix socket over http(s)
using Apache. However it's done, you're going to need a highly
customized podman-machine image to pull it off. I'm not aware of all
the specifics of doing this, but it seems hard.
What may be slightly simpler, is to see if you can operate the
gitlab-runner inside a container on the podman-machine. Then either
give it access to run nested podman containers, or leak the machine's
podman socket into the runner container.
Running podman inside podman is a little tricky to do, but if you ask
google you'll find a number of blogs on the topic. The keys are
mounting a host volume onto `$HOME/.local/share/containers` in the
container, running the container --privileged, and setting some
Hope that helps!
Chris Evich (he/him), RHCA III
Senior Quality Assurance Engineer
If it ain't broke, your hammer isn't wide 'nough.