Mounting volumes into docker not working

[agutenkunst]

If inside the job a volume is mounted into a docker container the mounted folder will be empty in this container.
I create a minimal example

name: CI

on: [push, pull_request]

jobs:
  my_job:
    runs-on: ubuntu-18.04
    steps:
      - run: "mkdir /tmp/folder && touch /tmp/folder/file && docker run -t -v /tmp/folder:/folder --entrypoint '' ubuntu:18.04 /bin/ls /folder"

In gh actions this works fine: See https://github.com/agutenkunst/nectos-act-docker-volume-mount-issue/runs/1368072778#step:2:20 ("file" is printed by /bin/ls)

Running locally

act -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04

does not give any output, indicating a failed mount.

[CI/my_job] 🚀  Start image=nektos/act-environments-ubuntu:18.04
[CI/my_job]   🐳  docker run image=nektos/act-environments-ubuntu:18.04 entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[CI/my_job] ⭐  Run mkdir /tmp/folder && touch /tmp/folder/file && docker run -t -v /tmp/folder:/folder --entrypoint '' ubuntu:18.04 /bin/ls /folder
[CI/my_job]   ✅  Success - mkdir /tmp/folder && touch /tmp/folder/file && docker run -t -v /tmp/folder:/folder --entrypoint '' ubuntu:18.04 /bin/ls /folder

This is also what I observed in a more complex real world use case. I am not sure if the image is actually Docker-in-Docker ready. Creating docker containers seems to work fine. Just not mounting something into them.

I check also on github and it seems that the runner user itself is "docker". Sounds like something according to https://docs.docker.com/engine/install/linux-postinstall/ is missing, but I am not sure.

[samfoley88]

I've just ran into this problem as well although slightly differently I think my workaround will work for anyone encountering it in future.

Cause
The cause is the fact Docker volume and bind commands (even when running inside an existing container) bind to the HOST file system so will ignore any pre-existing binds (like the bind of /github/workspace).
My best guess is that Github is processing the variables in the command with an awareness that the command is going to docker and so pre-processes the variables and passes the path from the host not the docker container you are already running in.

Workaround
My workaround for this is to make the paths match when running locally. So when passing in the volume to docker it matches both the variable/path in the host filesystem and the container file system.

Since the image mounts /github/workspace for the working directory inside the container if you run with your repository working directory as the folder on the host /github/workspace AND use --bind (so act binds straight to it and doesn't use a copy) then you can use ${{ github.workspace }} in Docker and get the expected outcome.

This command works for running act (note I'm using the 16GB image that matches Github exactly, you may not want to do this!)

act -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 --bind --directory /github/workspace

You can also run it without the --directory flag (but with --bind) if you are in /github/workspace

I use this one liner to make it easier, when run from the root of the repo it deletes the existing workspace (to clear out any changes/build artefacts etc) and then copies over the current directory before running act.

sudo rm -r /github/workspace/ && cp -r ./ /github/workspace && act -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 --bind --directory /github/workspace

Known Limitations
One of the biggest limitations I have found is that your repo is in /github/workspace and you can't do anything about this so if you need a working directory you need to add the directory in question inside that working folder with the repo. If you need to use additional repo's as part of your workflow it seems to work so long as the subfolder you use is in your .gitignore so it doesn't interact with the root repo.

Suggested long term fix
I would think long term Docker commands need to be identified as a special case and have the variable interpreted before it is passed to the CLI.

[github-actions]

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