-
Notifications
You must be signed in to change notification settings - Fork 441
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
Build Graal native images in a docker container #1250
Labels
graalvm
GraalVM releated issues
Comments
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 7, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 7, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 7, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
Implemented in #1251. |
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 7, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 8, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 8, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 8, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 8, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 8, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 8, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
jroper
added a commit
to jroper/sbt-native-packager
that referenced
this issue
Aug 8, 2019
Closes sbt#1250 This provides support for building Graal native images in a docker container.
muuki88
pushed a commit
that referenced
this issue
Aug 21, 2019
Closes #1250 This provides support for building Graal native images in a docker container.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This has been talked about a little in #1165, I'm creating an independent issue for it.
The big reason for building native images in a docker container is that Graal native images don't support cross compiling to different platforms from the host, so the native image you build will be specific for your platform. ie, if you have a Mac, and you build a native image there, you won't be able to deploy that image to Linux.
@adamw has a great blog post on building Graal native images in a docker container with sbt here, as a starting point.
In #1165, a good point is made that building in a docker container would be also useful for building debs and rpms, and so the feature should hopefully be somewhat reusable. That said, I'm not sure how much reuse there is to be had. The docker containers required to do the build are completely different, for Graal, you need one with Graal native-image installed. For debs, you need a Debian based distro image, and for rpms you need a RedHat based distro image. Furthermore, what needs to actually be done in those containers varies wildly depending on the task. For Graal, it's just a matter of running the container with a few directories mounted and passing a few arguments. For rpm/deb I would imagine it would first require installing a bunch of dependencies etc. I wouldn't be surprised if the only thing that makes sense to share between them is the location of the
docker
executable, from that point on, each build is going to do very different things with very different docker containers, I'd be surprised if there's anything else that could be shared.So I think the best approach is to implement them independently, and then if any common functionality is discovered, we can refactor them to share it, but I don't expect that any will be.
The text was updated successfully, but these errors were encountered: