Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DockerPlugin doesn't work with multiple main classes by default #1491

Closed
kubukoz opened this issue Jan 17, 2022 · 5 comments
Closed

DockerPlugin doesn't work with multiple main classes by default #1491

kubukoz opened this issue Jan 17, 2022 · 5 comments

Comments

@kubukoz
Copy link

kubukoz commented Jan 17, 2022

Expected behaviour

sbt Docker/publishLocal produces a runnable image or fails at build time in the presence of multiple main classes

Actual behaviour

The image fails startup

Information

  • What sbt-native-packager are you using: 1.9.7
  • What sbt version: 1.6.1
  • What is your build system: sbt
  • What package are you building docker
  • What version has your build tool: ???
  • What is your target system: macOS, also confirmed on Linux

Reproduction

  1. Make an sbt project using NP:
val root = project
  .in(file("."))
  .enablePlugins(JavaAppPackaging)
  .enablePlugins(DockerPlugin)
  1. Add multiple main classes
object Foo extends App
object Bar extends App
  1. sbt Docker/publishLocal

  2. Try to run the generated image:

$ docker run --rm -it sha256:46c53661a82306d95dbd9e9db28fa7e98d7f5ae4553d5c0091f0f71dfdbb8c97
docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/opt/docker/bin/root": stat /opt/docker/bin/root: no such file or directory: unknown.

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 (by Docker/mainClass or dockerEntrypoint, I'm not sure)?

@muuki88
Copy link
Contributor

muuki88 commented Jan 30, 2023

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

executableScriptName := normalizedName.value,

and without any scoping used here

dockerEntrypoint := Seq(s"${(defaultLinuxInstallLocation in Docker).value}/bin/${executableScriptName.value}"),

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

executableScriptName := executableScriptName.value,

@kubukoz
Copy link
Author

kubukoz commented Jan 30, 2023

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!

@muuki88
Copy link
Contributor

muuki88 commented Feb 9, 2023

@kubukoz I was able to work on this 😄 Release is out

@kubukoz
Copy link
Author

kubukoz commented Feb 9, 2023

thanks, I'm not getting a lot of time with SNP these days :)

@muuki88
Copy link
Contributor

muuki88 commented Feb 9, 2023

me neither 😓

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants