Podman Support

[peter-crist]

Github Local Actions Version

1.1.3

Act Version

...

Feature Description

Documentation mentions Docker is required. It would be nice if we could instead use Podman. I imagine this would be a common use case since a lot of folks try to avoid Docker's licensing and monetization.

[ChristopherHX]

Actually you can ignore the docker check, if you manually configure podman to work with nektos/act.

1. enable podman daemon / unix socket
2. set env variable globally on your system DOCKER_HOST to podman.sock
3. if podman cannot mount it's docker socket path enable act option --container-daemon-socket - / --container-daemon-socket /path/to/mountable/podman.sock

Podman was raised on my side as well ChristopherHX/github-act-runner#178, and yes it makes sense to use podman desktop.

Running act within docker:dind (as long you only run docker engine I don't think the license of docker is an issue) is possible the most elegant solution here, that has less potential to break for setups.
There are also ranger desktop and a lot of derivates of docker like runtimes

SanjulaGanepola could automate these steps, but I decided to not do that in nektos/act for myself.

[ChristopherHX]

Just for preservation, get the local unix socket of podman desktop / machine (macOS, possible linux too when you use podman machine optionally). podman windows uses a different path ConnectionInfo.PodmanPipe

podman machine inspect --format '{{ .ConnectionInfo.PodmanSocket.Path }}'

Then

podman info --format '{{ .Host.RemoteSocket.Path }}'

provides you the value of --container-daemon-socket

[SanjulaGanepola]

Hello @peter-crist. Thanks for opening this issue. I am indeed looking into better supporting podman and other options.

@ChristopherHX I had a look into this and need some clarification on how exactly this works in act. I am slightly confused as to why there are two ways to configuring this: DOCKER_HOST and --container-daemon-socket. In doing some testing, it seems like only DOCKER_HOST was only ever used and even in the cases where it wasn't set, it was using some default for it even when I passed in --container-daemon-socket. Looks like some other people are experiencing the same issue: nektos/act#2314

In my testing, I had both docker and podman running (and DOCKER_HOST was not set). In this test, I was trying to force it to use podman. Since docker was occupying the default Docker API pipe address, I tried to use --container-daemon-socket:

act --workflows ".github/workflows/abc.yaml" -v --container-daemon-socket "npipe:////./pipe/podman-machine-default"

and I noticed these log messages:

time="2024-12-09T00:48:01-05:00" level=debug msg="Handling container host and socket"
time="2024-12-09T00:48:01-05:00" level=debug msg="Conditional GET for notices etag=3d205e9f-d795-434f-b9c8-19df783d4a11"
time="2024-12-09T00:48:01-05:00" level=info msg="Using docker host 'npipe:////./pipe/docker_engine', and daemon socket 'npipe:////./pipe/podman-machine-default'"

It was unclear whether it was using docker or podman. So I had run podman machine stop and then ran the above command again, but it did not complain implying that it is using docker. In my second test, I did the same above steps but first setting DOCKER_HOST:

export DOCKER_HOST=npipe:////./pipe/podman-machine-default

then this command would work when I had podman started and not work when I didn't have it started:

act --workflows ".github/workflows/abc.yaml" -v

Is this indeed a bug in act?

[ChristopherHX]

I forget to mention --container-daemon-socket shouldn't have a protocol prefix and have the unix socket path of the wsl (vm).
Otherwise you cannot configure both separately, they don't match in podman desktop, while on linux they match and have the same values.

DOCKER_HOST should be the only thing with npipe or unix proto prefix

[ChristopherHX]

What is actually the output of podman info --format '{{ .Host.RemoteSocket.Path }}' on your windows?

For me it was the unix socket of the vm, which is the correct value for --container-daemon-socket

You set DOCKER_HOST correctly 👍

[SanjulaGanepola]

That command does not work for me. Any ideas why?

[SanjulaGanepola]

I am working on a PR to add the ability to add components in the hopes of addressing this issue (as well as #107).

Essentially, there will be two types of components with the below options. For each category, only one component is required so adding a new one will swap out the old one for the selected one.

1. Runners
   • nektos/act (the default)
   • Runner.Client
2. Container Engines
   • Docker (the default)
   • Podman

@ChristopherHX I have a few questions to be able to implement this:

1. In terms of container engines, what other options should we support considering what you have heard from people that use act and Runner.Client? Supporting each of these will require having the ability to start them from the extension. In the case of docker, we just start up Docker Desktop. As for podman, we can use podman machine start. Other options will require their specific commands.
2. Then in terms of using the selected container engine, what would the best way to do this? Should we set the DOCKER_HOST env var in the child_process or properly set the --container-daemon-socket. In either case, how can the extension retrieve what should be set for these?

[ChristopherHX]

That command does not work for me. Any ideas why?

Misconfigured podman Desktop? The podman cli is working for me on windows and macOS and finds the podman machine automatically using this command. (While I had to start podman first using the GUI due to me removing it from autostart, then the error was gone)

You can always fallback to guess it here is the value for me on both windows and macOS: /run/podman/podman.sock

So something like this on linux (opt into podman machine) and macOS.

# Use the npipe you figured out yourself on windows
# On macOS you cannot ever guess the value of the local unix socket
export DOCKER_HOST="unix://$(podman machine inspect --format '{{ .ConnectionInfo.PodmanSocket.Path }}')"
act --container-daemon-socket "$(podman info --format '{{ .Host.RemoteSocket.Path }}')"

1. In terms of container engines, what other options should we support considering what you have heard from people that use act and Runner.Client? Supporting each of these will require having the ability to start them from the extension. In the case of docker, we just start up Docker Desktop. As for podman, we can use podman machine start. Other options will require their specific commands.

in act, I remember of

• docker desktop (problems on linux due to non default docker.sock path)
• rancher-desktop
• podman

Runner.Client doesn't support act's options for docker daemon switching, podman not supported by the official runner that is used here. Needs a docker wrapper script in PATH that patches cli arguments, create the folder of the left hand in a -v <src>:<dest> mount, and needs to rewrite the container-daemon socket that actions/runner hardcodes.
Integrating https://github.com/actions/runner-container-hooks could work to allow dind or podman with precompiled actions/runner binaries (this backend has unsolved bugs).

Runner.Clients builtin small fork of actions/runner enables linux containers on macOS and windows (performs very bad) and windows containers on windows (act doesn't support this mode).

2. Then in terms of using the selected container engine, what would the best way to do this? Should we set the DOCKER_HOST env var in the child_process or properly set the --container-daemon-socket.

Need to set both for podman, rancher desktop, rootless docker engine

• DOCKER_HOST unix:// or npipe:// of socket to talk from the host to docker
• --container-daemon-socket to a filepath inside the VM hosting the Container Runtime, - disables the bind mount of the docker compatible docker.sock., if DOCKER_HOST is unset a compatible url can also be provided by this flag.

Yes you could also set only--container-daemon-socket to a value accepted by DOCKER_HOST, if you have luck it works. Big NO for podman.

In either case, how can the extension retrieve what should be set for these?

For podman I have written the commands I found last weekend. This was too complex for me to want to touch again in nektos/act, you always break workarounds if you change anything of dark magic.

[SanjulaGanepola]

Need to set both for podman, rancher desktop, rootless docker engine

@ChristopherHX Can you explain why exactly both are needed? It seems there is some priority logic here when I take a look at the act code related to this.

In either case, how can the extension retrieve what should be set for these?

For podman I have written the commands I found last weekend. This was too complex for me to want to touch again in nektos/act, you always break workarounds if you change anything of dark magic.

I am debating whether automatically retrieving these values for each of these different options will be feasible. Does it make more sense to simply provide an easier way to configure this DOCKER_HOST just in the VS Code Settings? Not sure how exactly that will work in terms of the UI as the Components view currently always shows Docker Engine.

As for Issue nektos/act#2314, is this a valid issue?

[ChristopherHX]

Can you explain why exactly both are needed?

You can have

• DOCKER_HOST=unix:///$HOME/.podman/whatever.sock (This is the caller of the docker engine)
• docker -v $HOME/.podman/whatever.sock:/var/run/docker.sock ubuntu:latest throws cannot mount (This mount is on the engine location, here a VM where $HOME/.podman/whatever.sock doesn't exist)
• Only docker -v /var/run/podman.sock:/var/run/docker.sock ubuntu:latest would work, or discarding the mount