nektos / act

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.

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

It's a big pain point to use Docker on Fedora 32.
It's not supported out of the box.

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

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

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.

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

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 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 ❯

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

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 containers/podman#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.

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 #303 (comment)
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 #303 (comment) , the authors (Shlomi Fish) hereby place this work, written in 2021, under CC0 / Public Domain.

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

🔧 💪

@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

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

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

act/pkg/container/docker_run.go

Line 455 in 96cf907

    
           pathTar, _, err := cr.cli.CopyFromContainer(ctx, cr.id, localEnv["GITHUB_PATH"])

I see two issues here:

podman should return a 403 according to the API [1]
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

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

why?

@catthehacker ,

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

https://github.com/nektos/act/search?q=CopyToContainer&type=code

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?

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.

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

1:

act/pkg/runner/run_context.go

Line 25 in 6ebcac3

const ActPath string = "/var/run/act"

2:

act/pkg/runner/run_context.go

Lines 83 to 86 in 6ebcac3

    
           mounts := map[string]string{ 
        
           	"act-toolcache": "/toolcache", 
        
           	name + "-env":   ActPath, 
        
           }

3:

act/pkg/container/docker_run.go

Lines 326 to 333 in 6ebcac3

    
           mounts := make([]mount.Mount, 0) 
        
           for mountSource, mountTarget := range input.Mounts { 
        
           	mounts = append(mounts, mount.Mount{ 
        
           		Type:   mount.TypeVolume, 
        
           		Source: mountSource, 
        
           		Target: mountTarget, 
        
           	}) 
        
           }

Also, the issue is not because of rootless daemon since I can reproduce it just fine in rootful podman

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

No, it still fails.

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

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

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

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

@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 (#303 (comment))

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

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"

Never mind me then

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

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

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

Is it possible to support lxc/lxd as well?

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.

😉 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 &)

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.

	mounts := map[string]string{
	"act-toolcache": "/toolcache",
	name + "-env": ActPath,
	}

	mounts := make([]mount.Mount, 0)
	for mountSource, mountTarget := range input.Mounts {
	mounts = append(mounts, mount.Mount{
	Type: mount.TypeVolume,
	Source: mountSource,
	Target: mountTarget,
	})
	}

Support for podman