[GH-ISSUE #303] Support for podman #214

Open
opened 2026-03-01 21:41:20 +03:00 by kerem · 39 comments
Owner

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 docker builtin with my OS, but instead podman (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 go docker bindings (like act does).

From what I understand, act uses docker bindings in order to

  • resolve and pull images
  • create and execute containers

All of this is possible with podman as well, so a solution could be to replace the direct docker bindings with an abstraction layer that would default to docker, but allows the user to select podman (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.

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 `docker` builtin with my OS, but instead [`podman`](https://github.com/containers/podman) (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 go `docker` bindings (like `act` does). From what I understand, `act` uses `docker` bindings in order to - resolve and pull images - create and execute containers All of this is possible with `podman` as well, so a solution could be to replace the direct `docker` bindings with an abstraction layer that would default to `docker`, but allows the user to select `podman` (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.
Author
Owner

@ianwalter commented on GitHub (Jul 18, 2020):

But GitHub Actions don't support other container runtimes do they?

<!-- gh-comment-id:660478667 --> @ianwalter commented on GitHub (Jul 18, 2020): But GitHub Actions don't support other container runtimes do they?
Author
Owner

@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 docker and podman use 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).

<!-- gh-comment-id:661704219 --> @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 `docker` and `podman` use the same kind of [image specification](https://github.com/opencontainers/image-spec), 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).
Author
Owner

@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.

<!-- gh-comment-id:667675401 --> @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.
Author
Owner

@github-actions[bot] commented on GitHub (Oct 2, 2020):

Issue is stale and will be closed in 7 days unless there is new activity

<!-- gh-comment-id:702463804 --> @github-actions[bot] commented on GitHub (Oct 2, 2020): Issue is stale and will be closed in 7 days unless there is new activity
Author
Owner

@anthr76 commented on GitHub (Mar 4, 2021):

Is there any chance this issue can be reopened? Looks like Podman support still isn't present.

<!-- gh-comment-id:790979703 --> @anthr76 commented on GitHub (Mar 4, 2021): Is there any chance this issue can be reopened? Looks like Podman support still isn't present.
Author
Owner

@catthehacker commented on GitHub (Mar 29, 2021):

podman support is something I'm tracking but no idea when will that gets done. Feel free to submit PR if you have something done.

<!-- gh-comment-id:809636100 --> @catthehacker commented on GitHub (Mar 29, 2021): `podman` support is something I'm tracking but no idea when will that gets done. Feel free to submit PR if you have something done.
Author
Owner

@abitrolly commented on GitHub (Apr 11, 2021):

For podman API service can be run with.

podman system service -t 0
# -t 0  means no timeout

Then it is possible to run act with DOCKER_HOST variable.

DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock act

That still didn't work for me. )

[build-test-release/build  ] 🚀  Start image=catthehacker/ubuntu:act-latest
Error: Error response from daemon: unable to find a name and tag match for catthehacker/ubuntu in repotags: no such image
<!-- gh-comment-id:817346185 --> @abitrolly commented on GitHub (Apr 11, 2021): For `podman` API service can be run with. ``` podman system service -t 0 # -t 0 means no timeout ``` Then it is possible to run `act` with `DOCKER_HOST` variable. ``` DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock act ``` That still didn't work for me. ) ``` [build-test-release/build ] 🚀 Start image=catthehacker/ubuntu:act-latest Error: Error response from daemon: unable to find a name and tag match for catthehacker/ubuntu in repotags: no such image ```
Author
Owner

@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

<!-- gh-comment-id:817350568 --> @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
Author
Owner

@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 act with podman. I don't recommend using podman right now unless you are persistent or trying to add podman support to act.

~/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 ❯
<!-- gh-comment-id:817425728 --> @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 `act` with `podman`. I don't recommend using `podman` right now unless you are persistent or trying to add `podman` support to `act`. ```shell ~/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 ❯ ```
Author
Owner

@catthehacker commented on GitHub (Apr 12, 2021):

[build-test-release/build  ] 🚀  Start image=catthehacker/ubuntu:act-latest
Error: Error response from daemon: unable to find a name and tag match for catthehacker/ubuntu in repotags: no such image

See /etc/containers/registries.conf or manpage containers-registries.conf(5)

<!-- gh-comment-id:817426916 --> @catthehacker commented on GitHub (Apr 12, 2021): > ``` > [build-test-release/build ] 🚀 Start image=catthehacker/ubuntu:act-latest > Error: Error response from daemon: unable to find a name and tag match for catthehacker/ubuntu in repotags: no such image > ``` See `/etc/containers/registries.conf` or manpage `containers-registries.conf(5)`
Author
Owner

@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:

systemctl enable --now --user podman.socket
systemctl start --user podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock

This seems to work for me. I did a quick test using one of the testdata files:

$ act -W pkg/runner/testdata/node/push.yml
[NodeJS Test/test] 🚀  Start image=catthehacker/ubuntu:act-latest
[NodeJS Test/test]   🐳  docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[NodeJS Test/test]   🐳  docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root
[NodeJS Test/test]   🐳  docker cp src=/tmp/act/. dst=/tmp/act
[NodeJS Test/test]   🐳  docker exec cmd=[mkdir -p /tmp/act] user=
[NodeJS Test/test] ⭐  Run actions/checkout@v2
[NodeJS Test/test]   ✅  Success - actions/checkout@v2
[NodeJS Test/test] ⭐  Run actions/setup-node@v1
INFO[0003]   ☁  git clone 'https://github.com/actions/setup-node' # ref=v1
[NodeJS Test/test]   🐳  docker cp src=/home/fugkco/.cache/act/actions-setup-node@v1/ dst=/var/run/act/actions/actions-setup-node@v1/
[NodeJS Test/test]   🐳  docker exec cmd=[mkdir -p /var/run/act/actions/actions-setup-node@v1/] user=
[NodeJS Test/test]   🐳  docker exec cmd=[node /var/run/act/actions/actions-setup-node@v1/dist/index.js] user=
[NodeJS Test/test]   💬  ::debug::isExplicit:
[NodeJS Test/test]   💬  ::debug::explicit? false
[NodeJS Test/test]   💬  ::debug::isExplicit: 14.17.1
[NodeJS Test/test]   💬  ::debug::explicit? true
[NodeJS Test/test]   💬  ::debug::evaluating 0 versions
[NodeJS Test/test]   💬  ::debug::match not found
[NodeJS Test/test]   💬  ::debug::evaluating 468 versions
[NodeJS Test/test]   💬  ::debug::matched: v12.6.0
[NodeJS Test/test]   💬  ::debug::isExplicit: 12.6.0
[NodeJS Test/test]   💬  ::debug::explicit? true
[NodeJS Test/test]   💬  ::debug::checking cache: /opt/hostedtoolcache/node/12.6.0/x64
[NodeJS Test/test]   💬  ::debug::not found
[NodeJS Test/test]   💬  ::debug::Downloading https://nodejs.org/dist/v12.6.0/node-v12.6.0-linux-x64.tar.gz
[NodeJS Test/test]   💬  ::debug::Destination /tmp/73b059bb-ed1e-454e-ad86-ea6896125553
[NodeJS Test/test]   💬  ::debug::download complete
[NodeJS Test/test]   💬  ::debug::Checking tar --version
[NodeJS Test/test]   💬  ::debug::tar (GNU tar) 1.30%0ACopyright (C) 2017 Free Software Foundation, Inc.%0ALicense GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.%0AThis is free software: you are free to change and redistribute it.%0AThere is NO WARRANTY, to the extent permitted by law.%0A%0AWritten by John Gilmore and Jay Fenlason.
| [command]/usr/bin/tar xz --warning=no-unknown-keyword -C /tmp/8bae3cbc-b364-4db1-91f7-e5dfc7a3d229 -f /tmp/73b059bb-ed1e-454e-ad86-ea6896125553
[NodeJS Test/test]   💬  ::debug::Caching tool node 12.6.0 x64
[NodeJS Test/test]   💬  ::debug::source dir: /tmp/8bae3cbc-b364-4db1-91f7-e5dfc7a3d229/node-v12.6.0-linux-x64
[NodeJS Test/test]   💬  ::debug::destination /opt/hostedtoolcache/node/12.6.0/x64
[NodeJS Test/test]   💬  ::debug::finished caching tool
| [command]/opt/hostedtoolcache/node/12.6.0/x64/bin/node --version
| v12.6.0
| [command]/opt/hostedtoolcache/node/12.6.0/x64/bin/npm --version
| 6.9.0
[NodeJS Test/test]   ❓  ##[add-matcher]/run/act/actions/actions-setup-node@v1/.github/tsc.json
[NodeJS Test/test]   ❓  ##[add-matcher]/run/act/actions/actions-setup-node@v1/.github/eslint-stylish.json
[NodeJS Test/test]   ❓  ##[add-matcher]/run/act/actions/actions-setup-node@v1/.github/eslint-compact.json
[NodeJS Test/test]   ✅  Success - actions/setup-node@v1
[NodeJS Test/test] ⭐  Run which node
[NodeJS Test/test]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /tmp/act/workflow/2] user=
| /opt/hostedtoolcache/node/12.6.0/x64/bin/node
[NodeJS Test/test]   ✅  Success - which node
[NodeJS Test/test] ⭐  Run Install Dependencies
[NodeJS Test/test]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /tmp/act/workflow/3] user=
| npm WARN saveError ENOENT: no such file or directory, open '/tmp/act/package.json'
| npm notice created a lockfile as package-lock.json. You should commit this file.
| npm WARN enoent ENOENT: no such file or directory, open '/tmp/act/package.json'
| npm WARN act No description
| npm WARN act No repository field.
| npm WARN act No README data
| npm WARN act No license field.
|
| up to date in 0.35s
| found 0 vulnerabilities
|
[NodeJS Test/test]   ✅  Success - Install Dependencies

I also ran the test suites. pkg/common and pkg/model worked fine. I'm assuming that is because there is no docker usage in those packages.

The pkg/container test suite return a single error because docker pull pulling 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/runner test suite expectedly picked up a lot more issues. The following tests failed:

  • TestRunEvent/basic
  • TestRunEvent/shells/python
  • TestRunEvent/uses-docker-url
  • TestRunEvent/remote-action-docker
  • TestRunEvent/local-action-docker-url
  • TestRunEvent/local-action-dockerfile
  • TestRunEvent/basic#01

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 shells/python test case), the rest had the following error:

    runner_test.go:79: 
        	Error Trace:	runner_test.go:79
        	Error:      	Expected nil, but got: unable to upgrade to tcp, received 409
        	Test:       	TestRunEvent/basic#01
        	Messages:   	/tmp/act/pkg/runner/testdata/basic
    --- FAIL: TestRunEvent/basic#01 (9.63s)

Not really sure what it means.

<!-- gh-comment-id:882069025 --> @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: ``` systemctl enable --now --user podman.socket systemctl start --user podman.socket export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock ``` This seems to work for me. I did a quick test using one of the testdata files: ``` $ act -W pkg/runner/testdata/node/push.yml [NodeJS Test/test] 🚀 Start image=catthehacker/ubuntu:act-latest [NodeJS Test/test] 🐳 docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[] [NodeJS Test/test] 🐳 docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root [NodeJS Test/test] 🐳 docker cp src=/tmp/act/. dst=/tmp/act [NodeJS Test/test] 🐳 docker exec cmd=[mkdir -p /tmp/act] user= [NodeJS Test/test] ⭐ Run actions/checkout@v2 [NodeJS Test/test] ✅ Success - actions/checkout@v2 [NodeJS Test/test] ⭐ Run actions/setup-node@v1 INFO[0003] ☁ git clone 'https://github.com/actions/setup-node' # ref=v1 [NodeJS Test/test] 🐳 docker cp src=/home/fugkco/.cache/act/actions-setup-node@v1/ dst=/var/run/act/actions/actions-setup-node@v1/ [NodeJS Test/test] 🐳 docker exec cmd=[mkdir -p /var/run/act/actions/actions-setup-node@v1/] user= [NodeJS Test/test] 🐳 docker exec cmd=[node /var/run/act/actions/actions-setup-node@v1/dist/index.js] user= [NodeJS Test/test] 💬 ::debug::isExplicit: [NodeJS Test/test] 💬 ::debug::explicit? false [NodeJS Test/test] 💬 ::debug::isExplicit: 14.17.1 [NodeJS Test/test] 💬 ::debug::explicit? true [NodeJS Test/test] 💬 ::debug::evaluating 0 versions [NodeJS Test/test] 💬 ::debug::match not found [NodeJS Test/test] 💬 ::debug::evaluating 468 versions [NodeJS Test/test] 💬 ::debug::matched: v12.6.0 [NodeJS Test/test] 💬 ::debug::isExplicit: 12.6.0 [NodeJS Test/test] 💬 ::debug::explicit? true [NodeJS Test/test] 💬 ::debug::checking cache: /opt/hostedtoolcache/node/12.6.0/x64 [NodeJS Test/test] 💬 ::debug::not found [NodeJS Test/test] 💬 ::debug::Downloading https://nodejs.org/dist/v12.6.0/node-v12.6.0-linux-x64.tar.gz [NodeJS Test/test] 💬 ::debug::Destination /tmp/73b059bb-ed1e-454e-ad86-ea6896125553 [NodeJS Test/test] 💬 ::debug::download complete [NodeJS Test/test] 💬 ::debug::Checking tar --version [NodeJS Test/test] 💬 ::debug::tar (GNU tar) 1.30%0ACopyright (C) 2017 Free Software Foundation, Inc.%0ALicense GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.%0AThis is free software: you are free to change and redistribute it.%0AThere is NO WARRANTY, to the extent permitted by law.%0A%0AWritten by John Gilmore and Jay Fenlason. | [command]/usr/bin/tar xz --warning=no-unknown-keyword -C /tmp/8bae3cbc-b364-4db1-91f7-e5dfc7a3d229 -f /tmp/73b059bb-ed1e-454e-ad86-ea6896125553 [NodeJS Test/test] 💬 ::debug::Caching tool node 12.6.0 x64 [NodeJS Test/test] 💬 ::debug::source dir: /tmp/8bae3cbc-b364-4db1-91f7-e5dfc7a3d229/node-v12.6.0-linux-x64 [NodeJS Test/test] 💬 ::debug::destination /opt/hostedtoolcache/node/12.6.0/x64 [NodeJS Test/test] 💬 ::debug::finished caching tool | [command]/opt/hostedtoolcache/node/12.6.0/x64/bin/node --version | v12.6.0 | [command]/opt/hostedtoolcache/node/12.6.0/x64/bin/npm --version | 6.9.0 [NodeJS Test/test] ❓ ##[add-matcher]/run/act/actions/actions-setup-node@v1/.github/tsc.json [NodeJS Test/test] ❓ ##[add-matcher]/run/act/actions/actions-setup-node@v1/.github/eslint-stylish.json [NodeJS Test/test] ❓ ##[add-matcher]/run/act/actions/actions-setup-node@v1/.github/eslint-compact.json [NodeJS Test/test] ✅ Success - actions/setup-node@v1 [NodeJS Test/test] ⭐ Run which node [NodeJS Test/test] 🐳 docker exec cmd=[bash --noprofile --norc -e -o pipefail /tmp/act/workflow/2] user= | /opt/hostedtoolcache/node/12.6.0/x64/bin/node [NodeJS Test/test] ✅ Success - which node [NodeJS Test/test] ⭐ Run Install Dependencies [NodeJS Test/test] 🐳 docker exec cmd=[bash --noprofile --norc -e -o pipefail /tmp/act/workflow/3] user= | npm WARN saveError ENOENT: no such file or directory, open '/tmp/act/package.json' | npm notice created a lockfile as package-lock.json. You should commit this file. | npm WARN enoent ENOENT: no such file or directory, open '/tmp/act/package.json' | npm WARN act No description | npm WARN act No repository field. | npm WARN act No README data | npm WARN act No license field. | | up to date in 0.35s | found 0 vulnerabilities | [NodeJS Test/test] ✅ Success - Install Dependencies ``` I also ran the test suites. `pkg/common` and `pkg/model` worked fine. I'm assuming that is because there is no docker usage in those packages. The `pkg/container` test suite return a single error because `docker pull` pulling 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/runner` test suite expectedly picked up a lot more issues. The following tests failed: - `TestRunEvent/basic` - `TestRunEvent/shells/python` - `TestRunEvent/uses-docker-url` - `TestRunEvent/remote-action-docker` - `TestRunEvent/local-action-docker-url` - `TestRunEvent/local-action-dockerfile` - `TestRunEvent/basic#01` 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 `shells/python` test case), the rest had the following error: ``` runner_test.go:79: Error Trace: runner_test.go:79 Error: Expected nil, but got: unable to upgrade to tcp, received 409 Test: TestRunEvent/basic#01 Messages: /tmp/act/pkg/runner/testdata/basic --- FAIL: TestRunEvent/basic#01 (9.63s) ``` Not really sure what it means.
Author
Owner

@shlomif commented on GitHub (Oct 7, 2021):

I decided to document the method I used to get act running on fedora 34 x86-64:

First, change the line in /etc/containers/registries.conf
to read:

short-name-mode="permissive"

Also run sudo dnf install podman-docker.

Per https://github.com/nektos/act/issues/303#issuecomment-882069025
run these commands:

systemctl enable --now --user podman.socket
systemctl start --user podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock

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.

<!-- gh-comment-id:937698375 --> @shlomif commented on GitHub (Oct 7, 2021): I decided to document the method I used to get `act` running on fedora 34 x86-64: — First, change the line in /etc/containers/registries.conf to read: ``` short-name-mode="permissive" ``` Also run `sudo dnf install podman-docker`. Per https://github.com/nektos/act/issues/303#issuecomment-882069025 run these commands: ``` systemctl enable --now --user podman.socket systemctl start --user podman.socket export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock ``` 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](https://creativecommons.org/choose/zero/).
Author
Owner

@xatier commented on GitHub (Nov 6, 2021):

Successfully invoked act on Archlinux.

Similar to @shlomif 's note above:

sudo pacman -S podman-docker
systemctl enable --now --user podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock

act --bind --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/build.yaml

🔧 💪

<!-- gh-comment-id:962403508 --> @xatier commented on GitHub (Nov 6, 2021): Successfully invoked `act` on Archlinux. Similar to @shlomif 's note above: ```text sudo pacman -S podman-docker systemctl enable --now --user podman.socket export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock act --bind --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/build.yaml ``` :wrench: :muscle:
Author
Owner

@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

zarathustra@wotan ~/code/hpi/manualaction (git)-[release/666] % act --bind --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/blank.yml                                       
[CI/build] 🚀  Start image=catthehacker/ubuntu:act-latest
[CI/build]   🐳  docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=false
[CI/build]   🐳  docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[CI/build]   🐳  docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[CI/build]   🐳  docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root workdir=
Error: Error: No such container:path: 6b902c4665332ed13c304bef90707797bd857408286929596fc33941bab8933e:/var/run/act/workflow/paths.txt

almost the same thing without --bind

zarathustra@wotan ~/code/hpi/manualaction (git)-[release/666] % act --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/blank.yml                                              
[CI/build] 🚀  Start image=catthehacker/ubuntu:act-latest
[CI/build]   🐳  docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=false
[CI/build]   🐳  docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[CI/build]   🐳  docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[CI/build]   🐳  docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root workdir=
[CI/build]   🐳  docker cp src=/home/zarathustra/code/hpi/manualaction/. dst=/home/zarathustra/code/hpi/manualaction
[CI/build]   🐳  docker exec cmd=[mkdir -p /home/zarathustra/code/hpi/manualaction] user= workdir=
Error: Error: No such container:path: f10cdc2dd68a4dfe618690fd2cfce0332566359fc03569d965976e4b05f04c9c:/var/run/act/workflow/paths.txt
<!-- gh-comment-id:979323210 --> @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 ``` zarathustra@wotan ~/code/hpi/manualaction (git)-[release/666] % act --bind --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/blank.yml [CI/build] 🚀 Start image=catthehacker/ubuntu:act-latest [CI/build] 🐳 docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=false [CI/build] 🐳 docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[] [CI/build] 🐳 docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[] [CI/build] 🐳 docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root workdir= Error: Error: No such container:path: 6b902c4665332ed13c304bef90707797bd857408286929596fc33941bab8933e:/var/run/act/workflow/paths.txt ``` almost the same thing without `--bind` ``` zarathustra@wotan ~/code/hpi/manualaction (git)-[release/666] % act --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/blank.yml [CI/build] 🚀 Start image=catthehacker/ubuntu:act-latest [CI/build] 🐳 docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=false [CI/build] 🐳 docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[] [CI/build] 🐳 docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[] [CI/build] 🐳 docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root workdir= [CI/build] 🐳 docker cp src=/home/zarathustra/code/hpi/manualaction/. dst=/home/zarathustra/code/hpi/manualaction [CI/build] 🐳 docker exec cmd=[mkdir -p /home/zarathustra/code/hpi/manualaction] user= workdir= Error: Error: No such container:path: f10cdc2dd68a4dfe618690fd2cfce0332566359fc03569d965976e4b05f04c9c:/var/run/act/workflow/paths.txt ```
Author
Owner

@xatier commented on GitHub (Nov 26, 2021):

not quite sure, but your workflow runs fine on my box. 🤔

$ act --bind --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/blank.yml 
[CI/build] 🚀  Start image=catthehacker/ubuntu:act-latest
[CI/build]   🐳  docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[CI/build]   🐳  docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root
[CI/build] ⭐  Run actions/checkout@v2
[CI/build]   ✅  Success - actions/checkout@v2
[CI/build] ⭐  Run Run a one-line script
[CI/build]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /tmp/manualaction/workflow/1] user=
| Hello, world!
[CI/build]   ✅  Success - Run a one-line script
[CI/build] ⭐  Run call script
[CI/build]   🐳  docker exec cmd=[sh -e -c /tmp/manualaction/workflow/2.sh] user=
| uid=0(root) gid=0(root) groups=0(root)
| nice try
[CI/build]   ✅  Success - call script

update: interestingly 0.2.24 worked fine but 0.2.25 doesn't work. Just upgraded my act and got the same result as yours. It seems to be a regression.

$ act --bind --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/blank.yml 
[CI/build] 🚀  Start image=catthehacker/ubuntu:act-latest
[CI/build]   🐳  docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=false
[CI/build]   🐳  docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[CI/build]   🐳  docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[CI/build]   🐳  docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root workdir=
Error: Error: No such container:path: cd739959a3738677258e918254a868024dbb905da3dfc26bbc1299f490e91e62:/var/run/act/workflow/paths.txt

$ act --version
act version 0.2.25
<!-- gh-comment-id:979638397 --> @xatier commented on GitHub (Nov 26, 2021): not quite sure, but your workflow runs fine on my box. :thinking: ```bash $ act --bind --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/blank.yml [CI/build] 🚀 Start image=catthehacker/ubuntu:act-latest [CI/build] 🐳 docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[] [CI/build] 🐳 docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root [CI/build] ⭐ Run actions/checkout@v2 [CI/build] ✅ Success - actions/checkout@v2 [CI/build] ⭐ Run Run a one-line script [CI/build] 🐳 docker exec cmd=[bash --noprofile --norc -e -o pipefail /tmp/manualaction/workflow/1] user= | Hello, world! [CI/build] ✅ Success - Run a one-line script [CI/build] ⭐ Run call script [CI/build] 🐳 docker exec cmd=[sh -e -c /tmp/manualaction/workflow/2.sh] user= | uid=0(root) gid=0(root) groups=0(root) | nice try [CI/build] ✅ Success - call script ``` update: interestingly 0.2.24 worked fine but 0.2.25 doesn't work. Just upgraded my `act` and got the same result as yours. It seems to be a regression. ```bash $ act --bind --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock -W .github/workflows/blank.yml [CI/build] 🚀 Start image=catthehacker/ubuntu:act-latest [CI/build] 🐳 docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=false [CI/build] 🐳 docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[] [CI/build] 🐳 docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[] [CI/build] 🐳 docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root workdir= Error: Error: No such container:path: cd739959a3738677258e918254a868024dbb905da3dfc26bbc1299f490e91e62:/var/run/act/workflow/paths.txt $ act --version act version 0.2.25 ```
Author
Owner

@xatier commented on GitHub (Nov 26, 2021):

@Loki-Afro ,

If we check podman's API server logs...

journalctl --user -u podman.service

We can find podman's API is saying something like this:

podman[4091977]: time="2021-11-25T20:45:18-06:00" level=error msg="copier: put: error checking directory \"/run/act/workflow\": mkdir /run/act/workflow: read-only file system"
podman[4091977]: @ - - [25/Nov/2021:20:45:18 -0600] "PUT /v1.40/containers/f0c3a814beab9de925069630803fe27599e34feb94aaa4debdf7bce0d5315779/archive?noOverwriteDirNonDir=true&path=%2Fvar%2Frun%2Fact%2F HTTP/1.1" 200 0 "" "Go-http-client/1.1"
podman[4091977]: @ - - [25/Nov/2021:20:45:18 -0600] "GET /v1.40/images/catthehacker/ubuntu:act-latest/json HTTP/1.1" 200 3393 "" "Go-http-client/1.1"
podman[4091977]: time="2021-11-25T20:45:18-06:00" level=info msg="Request Failed(Not Found): No such file or directory"
podman[4091977]: @ - - [25/Nov/2021:20:45:18 -0600] "GET /v1.40/containers/f0c3a814beab9de925069630803fe27599e34feb94aaa4debdf7bce0d5315779/archive?path=%2Fvar%2Frun%2Fact%2Fworkflow%2Fenvs.txt HTTP/1.1" 404 91 "" "Go-http-client/1.1"
podman[4091977]: time="2021-11-25T20:45:18-06:00" level=info msg="Request Failed(Not Found): No such file or directory"
podman[4091977]: @ - - [25/Nov/2021:20:45:18 -0600] "GET /v1.40/containers/f0c3a814beab9de925069630803fe27599e34feb94aaa4debdf7bce0d5315779/archive?path=%2Fvar%2Frun%2Fact%2Fworkflow%2Fpaths.txt HTTP/1.1" 404 91 "" "Go-http-client/1.1"

Interestingly podman is returning a 200 on a failure of PUT API call. That means, the mkdir command from act failed but docker.client.CopyToContainer passed.
github.com/moby/moby@7b9275c0da/client/container_copy.go (L47)

However though, since the directory doesn't actually exist, the following GET calls 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:

  1. podman should return a 403 according to the API [1]
  2. act should create a rw path in container so we are allowed to write files into the filesystem.

[1] https://docs.docker.com/engine/api/v1.41/#operation/PutContainerArchive

<!-- gh-comment-id:979675403 --> @xatier commented on GitHub (Nov 26, 2021): @Loki-Afro , If we check `podman`'s API server logs... ```bash journalctl --user -u podman.service ``` We can find podman's API is saying something like this: ``` podman[4091977]: time="2021-11-25T20:45:18-06:00" level=error msg="copier: put: error checking directory \"/run/act/workflow\": mkdir /run/act/workflow: read-only file system" podman[4091977]: @ - - [25/Nov/2021:20:45:18 -0600] "PUT /v1.40/containers/f0c3a814beab9de925069630803fe27599e34feb94aaa4debdf7bce0d5315779/archive?noOverwriteDirNonDir=true&path=%2Fvar%2Frun%2Fact%2F HTTP/1.1" 200 0 "" "Go-http-client/1.1" podman[4091977]: @ - - [25/Nov/2021:20:45:18 -0600] "GET /v1.40/images/catthehacker/ubuntu:act-latest/json HTTP/1.1" 200 3393 "" "Go-http-client/1.1" podman[4091977]: time="2021-11-25T20:45:18-06:00" level=info msg="Request Failed(Not Found): No such file or directory" podman[4091977]: @ - - [25/Nov/2021:20:45:18 -0600] "GET /v1.40/containers/f0c3a814beab9de925069630803fe27599e34feb94aaa4debdf7bce0d5315779/archive?path=%2Fvar%2Frun%2Fact%2Fworkflow%2Fenvs.txt HTTP/1.1" 404 91 "" "Go-http-client/1.1" podman[4091977]: time="2021-11-25T20:45:18-06:00" level=info msg="Request Failed(Not Found): No such file or directory" podman[4091977]: @ - - [25/Nov/2021:20:45:18 -0600] "GET /v1.40/containers/f0c3a814beab9de925069630803fe27599e34feb94aaa4debdf7bce0d5315779/archive?path=%2Fvar%2Frun%2Fact%2Fworkflow%2Fpaths.txt HTTP/1.1" 404 91 "" "Go-http-client/1.1" ``` Interestingly `podman` is returning a `200` on a failure of `PUT` API call. That means, the `mkdir` command from `act` failed but `docker.client.CopyToContainer` passed. https://github.com/moby/moby/blob/7b9275c0da707b030e62c96b679a976f31f929d3/client/container_copy.go#L47 However though, since the directory doesn't actually exist, the following `GET` calls to the API returned 404. So this code failed. https://github.com/nektos/act/blob/96cf907c5e1f4761ef6d91bb8e22487747a77f6b/pkg/container/docker_run.go#L455 ---- I see two issues here: 1. `podman` should return a `403` according to the API [1] 2. `act` should create a `rw` path in container so we are allowed to write files into the filesystem. [1] https://docs.docker.com/engine/api/v1.41/#operation/PutContainerArchive
Author
Owner

@catthehacker commented on GitHub (Nov 26, 2021):

2. act should create a rw container so we are allowed to write files into the filesystem.

why?

<!-- gh-comment-id:979676026 --> @catthehacker commented on GitHub (Nov 26, 2021): > 2\. `act` should create a `rw` container so we are allowed to write files into the filesystem. why?
Author
Owner

@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

<!-- gh-comment-id:979677011 --> @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
Author
Owner

@catthehacker commented on GitHub (Nov 26, 2021):

We are surely writing data into it, aren't we?

Yes, but why we should do that? It works just fine in Docker

Also, what is rw container?

<!-- gh-comment-id:979679828 --> @catthehacker commented on GitHub (Nov 26, 2021): > We are surely writing data into it, aren't we? Yes, but why we should do that? It works just fine in Docker Also, what is `rw` container?
Author
Owner

@xatier commented on GitHub (Nov 26, 2021):

In docker, act is using the root permission 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 /var is not allowed.

docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root

Here we are in fact (ab)using the root permission to write to the directory that we are technically not allowed to, I understand that act needs to write files inside the container, we should choose more explicit ways (e.g. rw volumes) for such directory creation.

<!-- gh-comment-id:979680302 --> @xatier commented on GitHub (Nov 26, 2021): In docker, `act` is using the `root` permission 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 `/var` is not allowed. ``` docker exec cmd=[mkdir -m 0777 -p /var/run/act] user=root ``` Here we are in fact (ab)using the `root` permission to write to the directory that we are technically not allowed to, I understand that `act` needs to write files inside the container, we should choose more explicit ways (e.g. `rw` volumes) for such directory creation.
Author
Owner

@catthehacker commented on GitHub (Nov 26, 2021):

But it's already a volume that is not restricted by ReadOnly option.

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

<!-- gh-comment-id:979683188 --> @catthehacker commented on GitHub (Nov 26, 2021): But it's already a volume that is not restricted by `ReadOnly` option. 1: https://github.com/nektos/act/blob/6ebcac37710ae5d4eb87f63f31d7e1be8fe3d217/pkg/runner/run_context.go#L25 2: https://github.com/nektos/act/blob/6ebcac37710ae5d4eb87f63f31d7e1be8fe3d217/pkg/runner/run_context.go#L83-L86 3: https://github.com/nektos/act/blob/6ebcac37710ae5d4eb87f63f31d7e1be8fe3d217/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
Author
Owner

@XVilka commented on GitHub (Nov 26, 2021):

Could it be because podman often requires --security-opt label=disable option to make things work with the volumes?

<!-- gh-comment-id:979684672 --> @XVilka commented on GitHub (Nov 26, 2021): Could it be because `podman` often requires `--security-opt label=disable` option to make things work with the volumes?
Author
Owner

@catthehacker commented on GitHub (Nov 26, 2021):

No, it still fails.

<!-- gh-comment-id:979686597 --> @catthehacker commented on GitHub (Nov 26, 2021): No, it still fails.
Author
Owner

@xatier commented on GitHub (Nov 26, 2021):

@catthehacker, I spent some time digging into this issue. :)

The below POC script is mimicking what act is doing in run_context.go, with some cross referenced debug logs from dockerd (to get POST parameters).

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 podman-docker API server, we can find the following from podman's API logs, as I pointed out earlier.

level=error msg="copier: put: error creating \"/run/act/act\": mkdir /run/act/act: read-only file system"

If we check the container spec generated by podman, we can find these are mounted as ro volumes.

$ 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 act is seeing, we failed to extract the tarball to this mount point.

$ 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 "/var/run/act:rw" ...

    "Mounts": [                                                                 
      {                                                                         
        "Source": "act-toolcache",                                              
        "Target": "/toolcache",                                                 
        "Type": "volume"                                                        
      },                                                                        
      {                                                                         
        "Source": "act-CI-build-env",                                           
        "Target": "/var/run/act:rw",                     <--------------                                                                                                      
        "Type": "volume"                                                        
      }                                                                         
    ]

We're able to see the proper rw mountpoint been created by podman.

$ 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 podman's man page [1]:

   Options specific to bind:

      · ro, readonly: true or false (default).

[1] https://docs.podman.io/en/latest/markdown/podman-run.1.html#mount-type-type-type-specific-option

I hope the above helps. :)

<!-- gh-comment-id:979752688 --> @xatier commented on GitHub (Nov 26, 2021): @catthehacker, I spent some time digging into this issue. :) The below POC script is mimicking what `act` is doing in `run_context.go`, with some cross referenced debug logs from `dockerd` (to get `POST` parameters). ```bash 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 `podman-docker` API server, we can find the following from `podman`'s API logs, as I pointed out earlier. ```text level=error msg="copier: put: error creating \"/run/act/act\": mkdir /run/act/act: read-only file system" ``` If we check the container spec generated by `podman`, we can find these are mounted as `ro` volumes. ```bash $ 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 `act` is seeing, we failed to extract the tarball to this mount point. ```bash $ 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 `"/var/run/act:rw"` ... ```text "Mounts": [ { "Source": "act-toolcache", "Target": "/toolcache", "Type": "volume" }, { "Source": "act-CI-build-env", "Target": "/var/run/act:rw", <-------------- "Type": "volume" } ] ``` We're able to see the proper `rw` mountpoint been created by `podman`. ```bash $ 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. ```bash $ podman exec -it act-CI-build ls /var/run/act/act bar foo ``` ---- Per `podman`'s man page [1]: ```text Options specific to bind: · ro, readonly: true or false (default). ``` [1] https://docs.podman.io/en/latest/markdown/podman-run.1.html#mount-type-type-type-specific-option I hope the above helps. :)
Author
Owner

@georgettica commented on GitHub (Dec 9, 2021):

hey! is there a docker image you are using to run podman?

<!-- gh-comment-id:989843749 --> @georgettica commented on GitHub (Dec 9, 2021): hey! is there a docker image you are using to run podman?
Author
Owner

@xatier commented on GitHub (Dec 10, 2021):

@Loki-Afro , @catthehacker , with both bugs fixed in podman, I'm able to run act with podman w/o problems again.

@georgettica , are you asking the image that act uses to run workflows? that'd be catthehacker/ubuntu:act-latest.

<!-- gh-comment-id:991186502 --> @xatier commented on GitHub (Dec 10, 2021): @Loki-Afro , @catthehacker , with both bugs fixed in `podman`, I'm able to run `act` with `podman` w/o problems again. @georgettica , are you asking the image that `act` uses to run workflows? that'd be `catthehacker/ubuntu:act-latest`.
Author
Owner

@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

<!-- gh-comment-id:991214392 --> @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
Author
Owner

@catthehacker commented on GitHub (Dec 10, 2021):

@catthehacker , with both bugs fixed in podman, I'm able to run act with podman w/o problems again.

Will check once podman will finish building on my machine.

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

I don't understand the question. There isn't any podman image for tests nor container runtime should be tested via any image.

<!-- gh-comment-id:991226505 --> @catthehacker commented on GitHub (Dec 10, 2021): > @catthehacker , with both bugs fixed in `podman`, I'm able to run `act` with `podman` w/o problems again. Will check once `podman` will finish building on my machine. > 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 I don't understand the question. There isn't any podman image for tests nor container runtime should be tested via any image.
Author
Owner

@xatier commented on GitHub (Dec 10, 2021):

@catthehacker thanks, here's the version on my box.

$ podman version
Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.4
Git Commit:   f6526ada1025c2e3f88745ba83b8b461ca659933
Built:        Thu Dec  9 12:30:40 2021
OS/Arch:      linux/amd64

@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)

<!-- gh-comment-id:991230118 --> @xatier commented on GitHub (Dec 10, 2021): @catthehacker thanks, here's the version on my box. ```text $ podman version Version: 3.4.4 API Version: 3.4.4 Go Version: go1.17.4 Git Commit: f6526ada1025c2e3f88745ba83b8b461ca659933 Built: Thu Dec 9 12:30:40 2021 OS/Arch: linux/amd64 ``` @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)
Author
Owner

@catthehacker commented on GitHub (Dec 10, 2021):

I still get failure though

--- FAIL: TestRunEvent (343.18s)
    --- FAIL: TestRunEvent/shells/python (0.09s)
        runner_test.go:79: 
            	Error Trace:	runner_test.go:79
            	Error:      	Expected nil, but got: Error response from daemon: No such image: node:16-buster: image not known
            	Test:       	TestRunEvent/shells/python
            	Messages:   	/home/cat/.dev/github.com/nektos/act/pkg/runner/testdata/shells/python
<!-- gh-comment-id:991248965 --> @catthehacker commented on GitHub (Dec 10, 2021): I still get failure though ``` --- FAIL: TestRunEvent (343.18s) --- FAIL: TestRunEvent/shells/python (0.09s) runner_test.go:79: Error Trace: runner_test.go:79 Error: Expected nil, but got: Error response from daemon: No such image: node:16-buster: image not known Test: TestRunEvent/shells/python Messages: /home/cat/.dev/github.com/nektos/act/pkg/runner/testdata/shells/python ```
Author
Owner

@xatier commented on GitHub (Dec 10, 2021):

that sounds like image short name issue. Consider adding the following to /etc/containers/registries.conf

unqualified-search-registries = ["docker.io"]

[aliases]
  node="docker.io/library/node"
<!-- gh-comment-id:991259813 --> @xatier commented on GitHub (Dec 10, 2021): that sounds like [image short name](https://www.redhat.com/sysadmin/container-image-short-names) issue. Consider adding the following to `/etc/containers/registries.conf` ```text unqualified-search-registries = ["docker.io"] [aliases] node="docker.io/library/node" ```
Author
Owner

@georgettica commented on GitHub (Dec 10, 2021):

Never mind me then

<!-- gh-comment-id:991260736 --> @georgettica commented on GitHub (Dec 10, 2021): Never mind me then
Author
Owner

@catthehacker commented on GitHub (Dec 10, 2021):

that sounds like image short name issue. Consider adding the following to /etc/containers/registries.conf

unqualified-search-registries = ["docker.io"]

[aliases]
  node="docker.io/library/node"

That's not short name issue

<!-- gh-comment-id:991265594 --> @catthehacker commented on GitHub (Dec 10, 2021): > that sounds like [image short name](https://www.redhat.com/sysadmin/container-image-short-names) issue. Consider adding the following to `/etc/containers/registries.conf` > > ``` > unqualified-search-registries = ["docker.io"] > > [aliases] > node="docker.io/library/node" > ``` That's not short name issue
Author
Owner

@ModProg commented on GitHub (Mar 1, 2022):

There seams to be an issue with --container-daemon-socket. I set it to unix:///run/user/1000/podman/podman.sock same as my $DOCKER_HOST but it failed with:

Error: Error response from daemon: fill out specgen: invalid option type "/var/run/docker.sock"

Got it working in the end by creating a symbolic link, still had to remove the continer-daemon-socket flag:

sudo ln -s /var/run/user/1000/podman/podman.sock /var/run/docker.sock
<!-- gh-comment-id:1055454917 --> @ModProg commented on GitHub (Mar 1, 2022): There seams to be an issue with `--container-daemon-socket`. I set it to `unix:///run/user/1000/podman/podman.sock` same as my `$DOCKER_HOST` but it failed with: ``` Error: Error response from daemon: fill out specgen: invalid option type "/var/run/docker.sock" ``` Got it working in the end by creating a symbolic link, still had to remove the `continer-daemon-socket` flag: ```sh sudo ln -s /var/run/user/1000/podman/podman.sock /var/run/docker.sock ```
Author
Owner

@catthehacker commented on GitHub (Mar 1, 2022):

There seams to be an issue with --container-daemon-socket.

No, there isn't

I set it to unix:///run/user/1000/podman/podman.sock

Incorrect socket address, please read act --help:

   --container-daemon-socket string   Path to Docker daemon socket which will be mounted to containers (default "/var/run/docker.sock") 
<!-- gh-comment-id:1055463877 --> @catthehacker commented on GitHub (Mar 1, 2022): > There seams to be an issue with `--container-daemon-socket`. No, there isn't > I set it to `unix:///run/user/1000/podman/podman.sock` Incorrect socket address, please read `act --help`: ``` --container-daemon-socket string Path to Docker daemon socket which will be mounted to containers (default "/var/run/docker.sock") ```
Author
Owner

@barrettj12 commented on GitHub (May 5, 2022):

Is it possible to support lxc/lxd as well?

<!-- gh-comment-id:1118195837 --> @barrettj12 commented on GitHub (May 5, 2022): Is it possible to support lxc/lxd as well?
Author
Owner

@catthehacker commented on GitHub (May 5, 2022):

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.
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 act to use.

<!-- gh-comment-id:1118458258 --> @catthehacker commented on GitHub (May 5, 2022): > 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. 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 `act` to use.
Author
Owner

@elasticdotventures commented on GitHub (May 31, 2022):

😉 Happy to report that I just got @nekos/act running on Win11 WSL2 ubuntu 22.04 with podman v3.4.4 (requires running podman system service -t 0 &)

<!-- gh-comment-id:1141721468 --> @elasticdotventures commented on GitHub (May 31, 2022): 😉 Happy to report that I just got `@nekos/act` running on Win11 WSL2 ubuntu 22.04 with podman v3.4.4 (requires running `podman system service -t 0 &`)
Author
Owner

@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, podman is not supported by act. 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.

<!-- gh-comment-id:1141883685 --> @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, `podman` is not supported by `act`. 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.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/act#214
No description provided.