On 4/19/23 10:42, jklaiho(a)iki.fi wrote: Hi, 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. 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 namespace options. Hope that helps! --- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer If it ain't broke, your hammer isn't wide 'nough.