-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for podman #303
Comments
But GitHub Actions don't support other container runtimes do they? |
Honestly I don't know what runtimes they're using. They're talking about "docker actions" in the docs, but as the actions spec only exposes very superficial parts of the underlying system it could really be anything. As both From my POV, there's no strong requirement to lock in with docker for the sake of running actions locally or in CI. A daemonless container runtime could even be beneficial for environments where users don't have enough access rights on their machine to install or control a docker daemon (think CI or corporate environments). |
It's a big pain point to use Docker on Fedora 32. |
This comment has been minimized.
This comment has been minimized.
Is there any chance this issue can be reopened? Looks like Podman support still isn't present. |
|
For
Then it is possible to run
That still didn't work for me. )
|
That's good info! You likely need the FQDN for the image. You can also set docker.io in the short names conf. I'm away from my computer but will try this out on my side |
That may be the case for you but others can and will have more issues when trying to run ~/act master ❯ go run main.go --userns keep-id -W .github/workflows/test-if.yml pj@alpix 03:37:47 AM
[Test what expressions result in true and false on GitHub/test-ifs-and-buts] 🚀 Start image=catthehacker/ubuntu:act-latest
[Test what expressions result in true and false on GitHub/test-ifs-and-buts] 🐳 docker run image=catthehacker/ubuntu:act-latest platform=linux/amd64 entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
Error: Error response from daemon: workdir "/home/<>/act" does not exist on container ee7494f4d7d35b7645a9d5d1445c2931499792b271f8bfcc197916f3c1869cf9
exit status 1
~/act master ❯ |
See |
Note, podman has pretty much full compatibility with docker API now. Rootful as of 3.0.0, and rootless as of 3.2.0. All you have to do is enable the podman socket and export docker host:
This seems to work for me. I did a quick test using one of the testdata files:
I also ran the test suites. The The
Tried to debug these but I struggled to work my way around the code (mostly trying to figure out where the errors are happening). Anyway, the only two errors were the previous mentioned error of the image not being found (only for the
Not really sure what it means. |
I decided to document the method I used to get — First, change the line in /etc/containers/registries.conf
Also run Per #303 (comment)
Then you can invoke License: Except for the code from #303 (comment) , the authors (Shlomi Fish) hereby place this work, written in 2021, under CC0 / Public Domain. |
Successfully invoked Similar to @shlomif 's note above:
🔧 💪 |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
If we check journalctl --user -u podman.service We can find podman's API is saying something like this:
Interestingly However though, since the directory doesn't actually exist, the following act/pkg/container/docker_run.go Line 455 in 96cf907
I see two issues here:
[1] https://docs.docker.com/engine/api/v1.41/#operation/PutContainerArchive |
why? |
We are surely writing data into it, aren't we? https://github.com/nektos/act/search?q=CopyToContainer&type=code |
Yes, but why we should do that? It works just fine in Docker Also, what is |
In docker, However, in (rootless)
Here we are in fact (ab)using the |
But it's already a volume that is not restricted by 1: Line 25 in 6ebcac3
2: Lines 83 to 86 in 6ebcac3
3: act/pkg/container/docker_run.go Lines 326 to 333 in 6ebcac3
Also, the issue is not because of rootless daemon since I can reproduce it just fine in rootful podman |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@catthehacker, I spent some time digging into this issue. :) The below POC script is mimicking what set -x
# pkg/runner/run_context.go#L157
# create
ID=$(curl -Ss -H 'Content-Type: application/json' \
--unix-socket /run/user/1000/podman/podman.sock \
-X POST \
-d '
{
"Entrypoint": [
"/usr/bin/tail",
"-f",
"/dev/null"
],
"Env": [
"RUNNER_TOOL_CACHE=/opt/hostedtoolcache",
"RUNNER_OS=Linux",
"RUNNER_TEMP=/tmp"
],
"HostConfig": {
"AutoRemove": false,
"Binds": [
"/run/user/1000/podman/podman.sock:/var/run/docker.sock",
"/tmp/manualaction:/tmp/manualaction"
],
"Mounts": [
{
"Source": "act-toolcache",
"Target": "/toolcache",
"Type": "volume"
},
{
"Source": "act-CI-build-env",
"Target": "/var/run/act",
"Type": "volume"
}
]
},
"Image": "catthehacker/ubuntu:act-latest",
"WorkingDir": "/tmp/manualaction"
}' \
'http://localhost/v1.40/containers/create?name=act-CI-build' \
| jq -r .Id)
# start
curl -Ss -H 'Content-Type: application/json' \
--unix-socket /run/user/1000/podman/podman.sock \
-X POST \
"http://localhost/v1.40/containers/$ID/start"
# exec `mkdir -m 0777 -p ActPath`
exec_ID=$(curl -Ss -H 'Content-Type: application/json' \
--unix-socket /run/user/1000/podman/podman.sock \
-X POST -d '{"Cmd": ["mkdir", "-m", "0777", "-p", "/var/run/act"], "Env": ["RUNNER_TOOL_CACHE=/opt/hostedtoolcache", "RUNNER_OS=Linux", "RUNNER_TEMP=/tmp"], "User": "root", "WorkingDir": ""}' \
"http://localhost/v1.40/containers/$ID/exec" \
| jq -r .Id)
curl -Ss -H 'Content-Type: application/json' \
--unix-socket /run/user/1000/podman/podman.sock \
-X POST -d '{"Detach": true, "Tty": false}' \
"http://localhost/v1.40/exec/$exec_ID/start"
curl -Ss -H 'Content-Type: application/json' \
--unix-socket /run/user/1000/podman/podman.sock \
-X GET \
"http://localhost/v1.40/exec/$exec_ID/json"
# copydir
curl -Ss -H 'Content-Type: application/json' \
--unix-socket /run/user/1000/podman/podman.sock \
-X PUT \
-T act.tar \
"http://localhost/v1.40/containers/$ID/archive?noOverwriteDirNonDir=true&path=%2Fvar%2Frun%2Fact%2F" Running this script against the
If we check the container spec generated by $ podman inspect act-CI-build | jq .[0].HostConfig.Binds
[
"act-toolcache:/toolcache:ro,rprivate,nosuid,nodev,rbind",
"act-CI-build-env:/var/run/act:ro,rprivate,nosuid,nodev,rbind",
"/run/user/1000/podman/podman.sock:/var/run/docker.sock:rw,rprivate,nosuid,nodev,rbind",
"/tmp/manualaction:/tmp/manualaction:rw,rprivate,nosuid,nodev,rbind"
] As the same behavior $ podman exec -it act-CI-build ls /var/run/act/act
ls: cannot access '/var/run/act/act': No such file or directory On the other hand, if we change the mount target to
We're able to see the proper $ podman inspect act-CI-build | jq .[0].HostConfig.Binds
[
"act-toolcache:/toolcache:ro,rprivate,nosuid,nodev,rbind",
"act-CI-build-env:/var/run/act:rw:ro,rprivate,nosuid,nodev,rbind", <----
"/run/user/1000/podman/podman.sock:/var/run/docker.sock:rw,rprivate,nosuid,nodev,rbind",
"/tmp/manualaction:/tmp/manualaction:rw,rprivate,nosuid,nodev,rbind"
] Also, we're able to see the contents of tarball inside the container. $ podman exec -it act-CI-build ls /var/run/act/act
bar foo Per
[1] https://docs.podman.io/en/latest/markdown/podman-run.1.html#mount-type-type-type-specific-option I hope the above helps. :) |
This comment was marked as off-topic.
This comment was marked as off-topic.
@Loki-Afro , @catthehacker , with both bugs fixed in @georgettica , are you asking the image that |
This comment was marked as off-topic.
This comment was marked as off-topic.
Will check once
I don't understand the question. There isn't any podman image for tests nor container runtime should be tested via any image. |
@catthehacker thanks, here's the version on my box.
@georgettica , sorry I still don't understand the question. Can you please elaborate what we're trying to do here? If we're adding more tests to |
I still get failure though
|
that sounds like image short name issue. Consider adding the following to
|
This comment was marked as off-topic.
This comment was marked as off-topic.
That's not short name issue |
This comment was marked as resolved.
This comment was marked as resolved.
No, there isn't
Incorrect socket address, please read
|
Is it possible to support lxc/lxd as well? |
They have Go bindings so it shouldn't be impossible, but GHA strictly depends on Docker for running actions, services and jobs. |
This comment was marked as spam.
This comment was marked as spam.
As this issue is all around everything, I'm renaming it to specify it's about |
I couldn't find anybody pointing out the missing support for container runtimes other than Docker, so here I go:
As a user of Fedora Silverblue, I don't have out-of-the-box
docker
builtin with my OS, but insteadpodman
(a daemonless and "rootless" userspace container engine).For purposes of building images and running containers it's directly compatible with
docker
, however as it doesn't have a daemon, there's no way to interact with it using godocker
bindings (likeact
does).From what I understand,
act
usesdocker
bindings in order toAll of this is possible with
podman
as well, so a solution could be to replace the directdocker
bindings with an abstraction layer that would default todocker
, but allows the user to selectpodman
(or another binding) to interact with containers or images.I would be interested in helping to get this to work, and want to raise this issue to ask for support on this topic.
The text was updated successfully, but these errors were encountered: