Currently dxCompiler clobbers the ENTRYPOINT of any docker image, because it uses the wdlTools dockerRunScript.ssp which sets the docker run argument --entrypoint /bin/bash \\. While this is fine for most workflows, it prevents a few workflows, or makes them much more verbose, and prevents some quality-of-life improvements in the image itself.
If this was changed to a template argument with default /bin/bash, e.g.
<%@ val entrypoint: String = "/bin/bash" %>
and then
# run as in the original configuration
docker run \\
-a stdout -a stderr \\
--memory=${maxMemory.toString} \\
--cidfile ${containerIdFile} \\
${bashDollar}{extraFlags} \\
--entrypoint "${entrypoint}" \\
-v ${hostRootDir}:${containerRootDir} \\
${imageName} ${commandFile}
This would (with additional Optional arguments in wdlTools and command line args in dxCompiler) allow users to specify their own entrypoint if desired.
Currently dxCompiler clobbers the ENTRYPOINT of any docker image, because it uses the wdlTools dockerRunScript.ssp which sets the docker run argument
--entrypoint /bin/bash \\. While this is fine for most workflows, it prevents a few workflows, or makes them much more verbose, and prevents some quality-of-life improvements in the image itself.If this was changed to a template argument with default /bin/bash, e.g.
and then
This would (with additional Optional arguments in wdlTools and command line args in dxCompiler) allow users to specify their own entrypoint if desired.