Open WildEgor opened 1 year ago
Did anyone figure this out?
i'm getting the same issue when using act
to develop locally
the docker docs seem to say that since entrypoint.sh
doesn't already exist it will be created as a directory
i'm getting the same issue when using
act
to develop locallythe docker docs seem to say that since
entrypoint.sh
doesn't already exist it will be created as a directory
seeing this also
Has anyone found a solution for this?
So apparently this doesn't work because of the nature of "Docker in Docker" When a DinD container gets ran, its docker socket gets connected to the host, so it's only a docker client in the container that's looping back and hooking into the main docker daemon on your host.
All the files and everything definitely exist in the DinD container, but the DinD container is looking for them on the host, not in the DinD container. This isn't normally a problem for Github because they run as VMs, not as containers. This seems to be a quirk with nektos/act and I'm currently looking into a way to work around this.
A year later (/j, happy 2024), I come with an update.
I've gotten to the point of getting a custom image with docker in docker working consistently and independently from the host.
The problem I'm facing now is getting /bin/bash: line 1: /entrypoint.sh: Permission denied
when actually running my workflow.
I've reached the point where I want to ask for further help here to figure this out.
Any extra help at this point would be fantastic.
I'm wondering if I have to set up docker for rootless EDIT: nevermind
I'm wondering if I have to set up docker for rootless EDIT: nevermind
happy 2024 :D Are you found a solution for this?
I'm wondering if I have to set up docker for rootless EDIT: nevermind
happy 2024 :D Are you found a solution for this?
Sorry, not yet I've burned myself out trying to figure the problem out past this point so I'm taking a small break
I'm using windows and I was using act to attempt local runners so I didn't use up my minutes. I abandoned it comepletely. I installed WSL 2, docker-desktop and Ubuntu (wsl). I created a self hosted runner on github, ran the install commands on the ubuntu terminal and now it works!
A year later (/j, happy 2024), I come with an update. I've gotten to the point of getting a custom image with docker in docker working consistently and independently from the host. The problem I'm facing now is getting
/bin/bash: line 1: /entrypoint.sh: Permission denied
when actually running my workflow.I've reached the point where I want to ask for further help here to figure this out.
@lkkuma, 2 really common reasons you'd get "permission denied" on a shell script are that the script itself is not executable, or that the reference to the script interpreter at the top of the script code does not exist (in other words, maybe your image doesn't have /bin/bash
). If you're running it on Ubuntu, that shouldn't be an issue, but if you're on something smaller, like Alpine linux, you'll just want to reference /bin/sh
at the top of the script instead. If the permissions are an issue, you'll want to run chmod 755 /entrypoint.sh
somewhere in your Dockerfile after it's COPY'd into the image.
I'm using windows and I was using act to attempt local runners so I didn't use up my minutes. I abandoned it comepletely. I installed WSL 2, docker-desktop and Ubuntu (wsl). I created a self hosted runner on github, ran the install commands on the ubuntu terminal and now it works!
I ended up trying this approach, but I'm having to re-run chmod or chown commands between each run, else set them in the actions file and type them as my runner terminal asks. Annoying. What am I doing wrong?
Same.
Due to the nature of DockerInDocker(dind), it is not necessary to dwell on solving this problem; here is a way to avoid similar problems:
Build an actions-runner/_work directory on the host, e.g. /root/var/unity-ci/actions-runner/_work
When building the game-ci container, in the Dockerfile: WORKDIR /root/var/unity-ci/
To run the game-ci container, use -v /root/var/unity-ci/actions-runner/_work:/root/var/unity-ci/actions-runner/_work
The trick here is to keep the _work path in the container the same as the _work path in the host.
Any updates on this?
Bug description
When using game-ci/unity-builder@v2 on self-hosted linux docker machine some error occurs: /bin/bash: /entrypoint.sh: Is a directory Error: The process '/usr/bin/docker' failed with exit code 126
How to reproduce
When step into build see errors.
Expected behavior
Run and build
Additional details
--volume /_work/_actions/game-ci/unity-builder/v2.1.2/dist/platforms/ubuntu/entrypoint.sh:/entrypoint.sh:z unityci/editor:ubuntu-2020.3.28f1-android-1 maybe this line broken?