The above dockerfile is probably accurate. As you can see there is some stuff going on in the backend when this container is built, so it's not a complete picture of what is going on, but it gets the gist of the thing across I think. Note that I'm pretty new to docker, so there's some things in there that probably don't make sense.
The errors I'm getting are really just /bin/sh: can't open '...'
. However, replacing CMD with something basic, like echo
or ls
doesn't fix that issue. However, having done a little testing, setting ENTRYPOINT
doesn't have any effect, just changes the name the sh
binary uses to report errors...
Sorry I'm just getting to this, but I think I've worked out a few issues in your example. Without the contents of your home directory, it's difficult to say for certain whether these fixes will work for you, but here's a list of the issues / fixes. I imagine that the
code.d
from the above example could easily replace thetest.d
from the below example.alpine-ldc
image is to serve as the first layer in a multi stage build. You should be basing your first layer off ofandrewbenton/alpine-ldc
and building your binary in that layer before passing it off to your final layer for running.USER
statement after theCMD
is effectively a no-op."ldc-flags": [ "-static" ]
to the properties so that a static binary is produced.&&
in the list of arguments toCMD
is just treated as another argument to/ldc/bin/ldc
instead of allowing execution of a subsequent command, which I believe is the intended effect.Small example below:
./source/test.d
:./Dockerfile.ldc-test
:./dub.json
:Build with:
docker build -f Dockerfile.ldc-test -t run-issue .
Run with:
docker run -it --rm run-issue:latest
ordocker run -it --rm run-issue:latest /test a b c d e f g
Please let me know whether that was helpful or not. I'd like to resolve your issue if I can.