How to get container volumes to work locally and remotely?

[flixman]

In my github workflow I am running everything though podman-in-podman. In the workflow I have the following block:

jobs:
    build:
        runs-on: registry.org/gitea/runners/podman:extended
        container:
            image: registry.org/gitea/runners/podman:extended
            volumes:
                - /mnt/act_runner/buildah-cache:/var/tmp/buildah-cache-1000

The problem I have is: when running this workflow locally, /mnt/act_runner/buildah-cache usually does not exist. I have tried using an env variable, but seems this is not supported (and the runner takes "${{ env.BUILDAH_CACHE }}" as a literal, complaining it is not a valid name - which is true). Is this a use case that is not supported, or am I doing something wrong?

[wellkilo]

The bind source is a host path, and it must exist when the job container is created—before any workflow step can create it. That is why creating it inside the job is too late.

For a cache that does not need a specific host path, use a named container volume instead:

jobs:
  build:
    container:
      image: registry.org/gitea/runners/podman:extended
      volumes:
        - buildah-cache:/var/tmp/buildah-cache-1000

This is the most portable form: source without a leading slash is treated as a named volume; an absolute source is treated as a host bind. act's runner implements that distinction in run_context.go.

If you require a bind mount, provision the directory on each runner host before starting the runner/act:

sudo mkdir -p /mnt/act_runner/buildah-cache

and keep the literal absolute mount in the workflow. Alternatively generate a small environment-specific workflow overlay before invoking act.

Do not rely on the env expression here. In current act, service-container volumes are explicitly passed through expression interpolation, but job-container volumes are consumed directly; more importantly, GitHub/Gitea must resolve the mount before job-level steps run, and support for contexts in this key is not portable. A named volume or pre-provisioned host path avoids both problems.

Also remember that a named volume is local to a particular runner host. If jobs can land on multiple hosts, use an external cache or arrange per-runner cache affinity rather than assuming that volume is shared cluster-wide.

[Icaro0310]

The catch is that container.volumes are passed straight to the container runtime, so the source path is resolved on the host running the daemon — not inside your job container, and not relative to the workflow. That's why it breaks between local and remote: /mnt/act_runner/buildah-cache has to exist on whichever machine runs podman/docker, and with podman-in-podman it must also be visible inside the outer podman container.

Easiest fix that works in both contexts: use a named volume instead of a host path. The daemon creates and manages it, so there's no host path dependency:

container:
    image: registry.org/gitea/runners/podman:extended
    volumes:
        - buildah-cache:/var/tmp/buildah-cache-1000

Named volumes persist across runs too, so your buildah cache survives.

If you genuinely need a host directory, make sure it's mounted into the act_runner/podman daemon container itself, and reference the path as seen by the daemon — not by the runner process.

—
Related work of mine: github.com/Icaro0310 · Website: icaro0310.github.io