[GH-ISSUE #2139] Automatically pre-start a Docker service inside the workflow containers #1020

New issue

Open

opened 2026-03-01 21:48:16 +03:00 by kerem · 0 comments

kerem commented

2026-03-01 21:48:16 +03:00

Owner

Originally created by @whisperity on GitHub (Dec 27, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/2139

Act version

act version 0.2.56

Feature description

I am looking for an easy way (preferably without modifying my workflow.yaml) to automatically start a Docker daemon inside the running workflow container (i.e., within what is spawned by act). I am using -P ubuntu-22.04=catthehacker/ubuntu:act-22.04, both act and the underlying image freshly pulled:

❯ docker images | grep catthehacker | choose 2 3..6
4b481b526128 5 days ago

The problem is that letting act mount the host Docker socket and thus running a Docker container configured by the workflow on the host's Docker environment results in that container's side effect being put to a wrong location.

I have the following workflow, which I heavily simplified for the sake of exposition:

steps:
  - uses: actions/checkout@v3  # Main repository "whisperity/Project".
  - uses: actions/checkout@v3
    with:
      repository: "organisation/Project-Resources"
      path: "Resources"

  - name: "Compile resources"
    # I do not have write rights to change what this Action does!
    uses: <a custom action which executes the 'run' script inside a pre-baked Docker environment>
    with:
      run: |
        apt-get install -yy --no-install-recommends <a bunch of dependencies...>
        cp -rv ./Resources /tmp/resource-project
        cd /tmp/resource-project
        make -j
        cp -rv /tmp/resource-project/Build ./Resources/

  - name: "Compile main project"
    run: |
      compiler RESOURCE_PATH=$(pwd)/Resources -j project

Here, I have a Docker container executed on a separately cloned repository which, amongst some other actions, creates some resources in a directory that must be available for later steps to work properly.

This works without any problems on the "real" GitHub Actions SaaS runners.

However, with act, it does not. Assume that I have my local repository in <host>//home/whisperity/proj. If I do act here, the Docker container created by act will have its own <docker-1>//home/whisperity/proj, where the side project is also cloned: <docker-1>//home/whisperity/proj/Resources.

However, when the reusable inner action spawns another Docker container, <docker-2>, it will do so through the host's socket. In there, <docker-2>//home/whisperity/proj (the working directory) is the same as <host>//home/whisperity/proj, but this inner action fails, as the checkout of the side repository did not happen to this location, failing the entire workflow. The "Resources" directory is only present in <docker-1>//.

Specifying --container-daemon-socket "-" will just result in the docker binary complaining there is no Docker service running within the container. Rightfully so.

My request is to have a way to automatically start a Docker daemon inside the containers that are running through act. Preferably, without having to touch the workflow file! This whole idea might be related to services (#173), but having control over a Docker daemon not attached to the main host is sort of like a "meta service". I see two ways forward for this:

A dedicated option, and feature support, within act and the client images, which will spawn Docker if the user requests it when running act. Or something like --container-daemon-socket "spawn"?
The option to specify a script that is executed every time a job starts running in a container (and vice versa, after all workflow actions had run?). Here, the user could manually script in any arbitrary action, not just the backgrounded starting of a Docker daemon.

Originally created by @whisperity on GitHub (Dec 27, 2023). Original GitHub issue: https://github.com/nektos/act/issues/2139 ### Act version act version 0.2.56 ### Feature description I am looking for an easy way (preferably without modifying my `workflow.yaml`) to automatically start a Docker daemon **inside** the running workflow container (i.e., within what is spawned by _`act`_). I am using *`-P ubuntu-22.04=catthehacker/ubuntu:act-22.04`*, both _`act`_ and the underlying image freshly pulled: ``` ❯ docker images | grep catthehacker | choose 2 3..6 4b481b526128 5 days ago ``` The problem is that letting _`act`_ mount the host Docker socket and thus running a Docker container configured by the workflow on the host's Docker environment results in that container's side effect being put to a wrong location. I have the following workflow, which I heavily simplified for the sake of exposition: ```yaml steps: - uses: actions/checkout@v3 # Main repository "whisperity/Project". - uses: actions/checkout@v3 with: repository: "organisation/Project-Resources" path: "Resources" - name: "Compile resources" # I do not have write rights to change what this Action does! uses: <a custom action which executes the 'run' script inside a pre-baked Docker environment> with: run: | apt-get install -yy --no-install-recommends <a bunch of dependencies...> cp -rv ./Resources /tmp/resource-project cd /tmp/resource-project make -j cp -rv /tmp/resource-project/Build ./Resources/ - name: "Compile main project" run: | compiler RESOURCE_PATH=$(pwd)/Resources -j project ``` Here, I have a Docker container executed on a separately cloned repository which, amongst some other actions, creates some resources in a directory that **must** be available for later steps to work properly. **This works without any problems on the "real" GitHub Actions SaaS runners.** However, with _`act`_, it does not. Assume that I have my local repository in `<host>//home/whisperity/proj`. If I do `act` here, the Docker container created by _`act`_ will have its own `<docker-1>//home/whisperity/proj`, where the side project is also cloned: `<docker-1>//home/whisperity/proj/Resources`. However, when the reusable inner action spawns another Docker container, `<docker-2>`, it will do so through the **host**'s socket. In there, `<docker-2>//home/whisperity/proj` (the working directory) is the same as `<host>//home/whisperity/proj`, but this inner action fails, as the checkout of the side repository did **not** happen to this location, failing the entire workflow. The _"Resources"_ directory is only present in `<docker-1>//`. Specifying `--container-daemon-socket "-"` will just result in the _`docker`_ binary complaining there is no Docker service running within the container. Rightfully so. My request is to have a way to automatically start a Docker daemon _inside the containers_ that are running through _`act`_. Preferably, without having to touch the workflow file! This whole idea might be related to services (#173), but having control over a Docker daemon not attached to the main host is sort of like a "meta service". I see two ways forward for this: - A dedicated option, and feature support, within _`act`_ and the client images, which will spawn Docker if the user requests it when running `act`. Or something like `--container-daemon-socket "spawn"`? - The option to specify a script that is executed every time a job starts running in a container (and vice versa, after all workflow actions had run?). Here, the user could manually script in any arbitrary action, not just the backgrounded starting of a Docker daemon.

kerem added the

kind/feature-request

label

2026-03-01 21:48:16 +03:00

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#1020

No description provided.

Rows
Columns