External docker build #637
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is prompted by various issues around our handling of arguments and how this clashes with -- and -D argument handling by both sbt-pack and sbt-native-packager Instead, we build scip-java entirely inside the docker container and point `scip-java` command directly at the jar, to exclude any possibility of weirdness introduced by launcher scripts. Additionally, this allows anyone to build a docker container without having JVM and SBT installed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #579
Problem
The original issue in 579 was caused by our usage of sbt-pack and its special handling of
-Darguments: https://github.com/xerial/sbt-pack/blob/master/src/main/twirl/xerial/sbt/pack/launch.scala.txt#L139Initially I thought that switching to sbt-native-packager would fix this, but after implementing it I realised that this would require changing the CLI contract as
--needs to be handled by the launcher script first, then moped: https://github.com/sbt/sbt-native-packager/blob/master/src/main/resources/com/typesafe/sbt/packager/archetypes/scripts/bash-template#L338In the end, I feel strongly that these packaging solutions are not suitable for our use case as we want the CLI interface to stay stable and
--to be handled by moped alone.Solution
We move our entire Docker build into a self-contained Dockerfile - inside of which we publish the CLI and bootstrap it with coursier in the necessary location.
Everything else remains the same, but this guarantees that the arguments are passed verbatim to the scip-java jar.
As a positive side effect, this makes it easier to build the docker container - you don't need JDK installed, just
docker build . -t scip-java-localis enough.Test plan