mirror of
https://github.com/nektos/act.git
synced 2026-04-26 01:15:51 +03:00
[GH-ISSUE #303] Support for podman #214
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#214
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lwille on GitHub (Jul 9, 2020).
Original GitHub issue: https://github.com/nektos/act/issues/303
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
dockerbuiltin 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 godockerbindings (likeactdoes).From what I understand,
actusesdockerbindings in order toAll of this is possible with
podmanas well, so a solution could be to replace the directdockerbindings 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.
@ianwalter commented on GitHub (Jul 18, 2020):
But GitHub Actions don't support other container runtimes do they?
@lwille commented on GitHub (Jul 21, 2020):
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
dockerandpodmanuse the same kind of image specification, images are compatible with both and other runtimes.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).
@likern commented on GitHub (Aug 2, 2020):
It's a big pain point to use Docker on Fedora 32.
It's not supported out of the box.
@github-actions[bot] commented on GitHub (Oct 2, 2020):
Issue is stale and will be closed in 7 days unless there is new activity
@anthr76 commented on GitHub (Mar 4, 2021):
Is there any chance this issue can be reopened? Looks like Podman support still isn't present.
@catthehacker commented on GitHub (Mar 29, 2021):
podmansupport is something I'm tracking but no idea when will that gets done. Feel free to submit PR if you have something done.@abitrolly commented on GitHub (Apr 11, 2021):
For
podmanAPI service can be run with.Then it is possible to run
actwithDOCKER_HOSTvariable.That still didn't work for me. )
@anthr76 commented on GitHub (Apr 11, 2021):
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
@catthehacker commented on GitHub (Apr 12, 2021):
That may be the case for you but others can and will have more issues when trying to run
actwithpodman. I don't recommend usingpodmanright now unless you are persistent or trying to addpodmansupport toact.@catthehacker commented on GitHub (Apr 12, 2021):
See
/etc/containers/registries.confor manpagecontainers-registries.conf(5)@fugkco commented on GitHub (Jul 18, 2021):
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.
pkg/commonandpkg/modelworked fine. I'm assuming that is because there is no docker usage in those packages.The
pkg/containertest suite return a single error becausedocker pullpulling the wrong image when specifying platform. I've raised a bug for podman https://github.com/containers/podman/issues/10977, as it affects docker cli too.The
pkg/runnertest suite expectedly picked up a lot more issues. The following tests failed:TestRunEvent/basicTestRunEvent/shells/pythonTestRunEvent/uses-docker-urlTestRunEvent/remote-action-dockerTestRunEvent/local-action-docker-urlTestRunEvent/local-action-dockerfileTestRunEvent/basic#01Tried 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
shells/pythontest case), the rest had the following error:Not really sure what it means.
@shlomif commented on GitHub (Oct 7, 2021):
I decided to document the method I used to get
actrunning on fedora 34 x86-64:—
First, change the line in /etc/containers/registries.conf
to read:
Also run
sudo dnf install podman-docker.Per https://github.com/nektos/act/issues/303#issuecomment-882069025
run these commands:
Then you can invoke
act.License:
Except for the code from https://github.com/nektos/act/issues/303#issuecomment-882069025 , the authors (Shlomi Fish) hereby place this work, written in 2021, under CC0 / Public Domain.
@xatier commented on GitHub (Nov 6, 2021):
Successfully invoked
acton Archlinux.Similar to @shlomif 's note above:
🔧 💪
@Loki-Afro commented on GitHub (Nov 25, 2021):
@xatier
any clue where this issue is coming from?
fedora 35 with newest stuff, podman version 3.4.2
almost the same thing without
--bind@xatier commented on GitHub (Nov 26, 2021):
not quite sure, but your workflow runs fine on my box. 🤔
update: interestingly 0.2.24 worked fine but 0.2.25 doesn't work. Just upgraded my
actand got the same result as yours. It seems to be a regression.@xatier commented on GitHub (Nov 26, 2021):
@Loki-Afro ,
If we check
podman's API server logs...We can find podman's API is saying something like this:
Interestingly
podmanis returning a200on a failure ofPUTAPI call. That means, themkdircommand fromactfailed butdocker.client.CopyToContainerpassed.github.com/moby/moby@7b9275c0da/client/container_copy.go (L47)However though, since the directory doesn't actually exist, the following
GETcalls to the API returned 404. So this code failed.github.com/nektos/act@96cf907c5e/pkg/container/docker_run.go (L455)I see two issues here:
podmanshould return a403according to the API [1]actshould create arwpath in container so we are allowed to write files into the filesystem.[1] https://docs.docker.com/engine/api/v1.41/#operation/PutContainerArchive
@catthehacker commented on GitHub (Nov 26, 2021):
why?
@xatier commented on GitHub (Nov 26, 2021):
@catthehacker ,
We are surely writing data into it, aren't we?
https://github.com/nektos/act/search?q=CopyToContainer&type=code
@catthehacker commented on GitHub (Nov 26, 2021):
Yes, but why we should do that? It works just fine in Docker
Also, what is
rwcontainer?@xatier commented on GitHub (Nov 26, 2021):
In docker,
actis using therootpermission to setup this directory, which would for sure pass the check, root can write anything inside the containers anyways (leaky abstraction!).However, in (rootless)
podman, writing to/varis not allowed.Here we are in fact (ab)using the
rootpermission to write to the directory that we are technically not allowed to, I understand thatactneeds to write files inside the container, we should choose more explicit ways (e.g.rwvolumes) for such directory creation.@catthehacker commented on GitHub (Nov 26, 2021):
But it's already a volume that is not restricted by
ReadOnlyoption.1:
github.com/nektos/act@6ebcac3771/pkg/runner/run_context.go (L25)2:
github.com/nektos/act@6ebcac3771/pkg/runner/run_context.go (L83-L86)3:
github.com/nektos/act@6ebcac3771/pkg/container/docker_run.go (L326-L333)Also, the issue is not because of rootless daemon since I can reproduce it just fine in rootful podman
@XVilka commented on GitHub (Nov 26, 2021):
Could it be because
podmanoften requires--security-opt label=disableoption to make things work with the volumes?@catthehacker commented on GitHub (Nov 26, 2021):
No, it still fails.
@xatier commented on GitHub (Nov 26, 2021):
@catthehacker, I spent some time digging into this issue. :)
The below POC script is mimicking what
actis doing inrun_context.go, with some cross referenced debug logs fromdockerd(to getPOSTparameters).Running this script against the
podman-dockerAPI server, we can find the following frompodman's API logs, as I pointed out earlier.If we check the container spec generated by
podman, we can find these are mounted asrovolumes.As the same behavior
actis seeing, we failed to extract the tarball to this mount point.On the other hand, if we change the mount target to
"/var/run/act:rw"...We're able to see the proper
rwmountpoint been created bypodman.Also, we're able to see the contents of tarball inside the container.
Per
podman's man page [1]:[1] https://docs.podman.io/en/latest/markdown/podman-run.1.html#mount-type-type-type-specific-option
I hope the above helps. :)
@georgettica commented on GitHub (Dec 9, 2021):
hey! is there a docker image you are using to run podman?
@xatier commented on GitHub (Dec 10, 2021):
@Loki-Afro , @catthehacker , with both bugs fixed in
podman, I'm able to runactwithpodmanw/o problems again.@georgettica , are you asking the image that
actuses to run workflows? that'd becatthehacker/ubuntu:act-latest.@georgettica commented on GitHub (Dec 10, 2021):
I meant the image to run tests with podman.
I guessed each had an image that can be pulled so additional local tests can follow
@catthehacker commented on GitHub (Dec 10, 2021):
Will check once
podmanwill finish building on my machine.I don't understand the question. There isn't any podman image for tests nor container runtime should be tested via any image.
@xatier commented on GitHub (Dec 10, 2021):
@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
podman, you can follow the API calls in the script above (https://github.com/nektos/act/issues/303#issuecomment-979752688)@catthehacker commented on GitHub (Dec 10, 2021):
I still get failure though
@xatier commented on GitHub (Dec 10, 2021):
that sounds like image short name issue. Consider adding the following to
/etc/containers/registries.conf@georgettica commented on GitHub (Dec 10, 2021):
Never mind me then
@catthehacker commented on GitHub (Dec 10, 2021):
That's not short name issue
@ModProg commented on GitHub (Mar 1, 2022):
There seams to be an issue with
--container-daemon-socket. I set it tounix:///run/user/1000/podman/podman.socksame as my$DOCKER_HOSTbut it failed with:Got it working in the end by creating a symbolic link, still had to remove the
continer-daemon-socketflag:@catthehacker commented on GitHub (Mar 1, 2022):
No, there isn't
Incorrect socket address, please read
act --help:@barrettj12 commented on GitHub (May 5, 2022):
Is it possible to support lxc/lxd as well?
@catthehacker commented on GitHub (May 5, 2022):
They have Go bindings so it shouldn't be impossible, but GHA strictly depends on Docker for running actions, services and jobs.
I haven't touched LXC in a long time so I'm unsure about the capabilities and how easy it would be to provide same API for
actto use.@elasticdotventures commented on GitHub (May 31, 2022):
😉 Happy to report that I just got
@nekos/actrunning on Win11 WSL2 ubuntu 22.04 with podman v3.4.4 (requires runningpodman system service -t 0 &)@catthehacker commented on GitHub (May 31, 2022):
As this issue is all around everything, I'm renaming it to specify it's about
podman(since that was original request).As of today,
podmanis not supported byact. It probably will work for some people, but it doesn't pass our tests.There is PR opened for adding CI. If you want to help, ping me on gitter/matrix in act room/channel.