Closed kubukoz closed 1 year ago
Thanks for your patience. This is hitting more and more users now. Would you like to open a PR to fix this?
The executableScriptName
is set here initially
and without any scoping used here
An option would be to keep this a docker thing. And add
Docker / executableScriptName := normalizedName.value
dockerEntrypoint := Seq(s"${(defaultLinuxInstallLocation in Docker).value}/bin/${(Docker / executableScriptName).value}"),
and remove the executableScriptName
entry here
I'll see when I have the time to dig into it and properly test the outcome, but if someone wants to pick it up earlier feel free to do so!
@kubukoz I was able to work on this :smile: Release is out
thanks, I'm not getting a lot of time with SNP these days :)
me neither :sweat:
Expected behaviour
sbt Docker/publishLocal
produces a runnable image or fails at build time in the presence of multiple main classesActual behaviour
The image fails startup
Information
Reproduction
sbt Docker/publishLocal
Try to run the generated image:
Docker/dockerEntrypoint
points to/opt/docker/bin/root
, and setting it to a specific binary helps. Clearly the names are set by a heuristic documented in the docs.However, I don't think the Docker plugin's behavior is intuitive, because if you add a new main class to a working build you'll suddenly be unable to run the images.
Maybe
Docker/stage
should fail if there are many main classes and none of them is explicitly chosen (byDocker/mainClass
ordockerEntrypoint
, I'm not sure)?