Workflow fails when running steps in a container #25094
Replies: 12 comments
-
I’m having the exact same issue currently. Did you find a work around? |
Beta Was this translation helpful? Give feedback.
-
I haven’t figured out a solution yet. GitHub must be having issues because now the workflow isn’t even running. |
Beta Was this translation helpful? Give feedback.
-
I’m having the eact same one as well. |
Beta Was this translation helpful? Give feedback.
-
I have the same issue. It works when you use “-slim” images. Somehow, the alpine container is not detected as running. |
Beta Was this translation helpful? Give feedback.
-
Either of these work. I prefer the “slim” one, because in the alpine one (in this form) all commands get thrown together in one github actions step. |
Beta Was this translation helpful? Give feedback.
-
This solved it for me too. Seems Alpine images has a bug in the runner. |
Beta Was this translation helpful? Give feedback.
-
I had the same issue, i tried to look into what is happening a bit and it mounts tools from the host into the container and then overwrites the entrypoint with node to run setInterval to keep the container running.
This is naturally a bad idea, as those binaries aren’t compiled for alpine. I also found some requirements on the Azure DevOps Site, which are prob. in effect for GitHub Actions too - but i didnt find a notice about this in the gh action docs:
Seems pretty overkill though, to have dependencies on glibc and nodejs just to run setInterval to keep the container running, there are better ways like for example: _/bin/sh -c “tail -f /dev/null” or just by using sleep _that do not have any dependencies and should also be usable everywhere where bash is available. Sadly we can’t affect the entrypoint / args passed to the main container, so the only possible way to workaround this is to either install glibc and all dependencies into the alpine image (not viable), or to not use container and define the image to use for every single command (bloats workflow up quite a bit). Im working on a different workaround that i will share later. |
Beta Was this translation helpful? Give feedback.
-
Kudos for the research :slight_smile: it does seem weird that they don’t just tail to dev/null to keep the container up, that’s a pretty standard way of operating. |
Beta Was this translation helpful? Give feedback.
-
This is most definitely not “solved”. Using the |
Beta Was this translation helpful? Give feedback.
-
I am actually working on making this exact change. In earlier versions, we were running actions such as git checkout by default, and they were written in JavaScript, so naturally we had a higher level of dependency on Node here. After shedding that, we now have legitimate scenarios like the ones described here that shouldn’t need Node at all. Expect that update soon! |
Beta Was this translation helpful? Give feedback.
-
This should now be fully supported https://github.blog/changelog/2019-09-18-improvements-to-github-actions/ |
Beta Was this translation helpful? Give feedback.
-
Is it possible to run same commands in three docker containers with elixir 1.9, 1.8 and 1.7 using matrix strategy? |
Beta Was this translation helpful? Give feedback.
-
I’ve just started setting up a workflow for one of my Elixir projects. I began with a simple workflow that just echos text in the shell. Here is that worklow:
This workflow completes successfully.
Next, I attempted to run the same commands inside a container with this workflow definition:
This workflow fails with the error
Error response from daemon: Container XXXXXX is not running
.I’ve just started to work with GitHub Actions, so maybe there is something I’ve overlooked. Can anyone help me resolve this issue? According to Workflow syntax for GitHub Actions, in the Container section: “A container to run any steps in a job that don’t already specify a container.” My assumption is that the container would be started and the steps would be run inside the Elixir Alpine Docker image.
Beta Was this translation helpful? Give feedback.
All reactions