Open andreaTP opened 3 years ago
Oh, cloudflow was using sbt-native-packager, but I guess it was changed at some point?
One thing to keep an eye out if we do this is that the images are still built efficiently. The app artifacts should be in a single layer so only 1 small layer change is required for each new image push. sbt-native-packager (IIRC) puts all artifacts in a single directory (including dependencies) which can result in a bigger layer every time the app is changed.
This has been a topic of some debate to make this functionality the default in sbt-native-packager for Docker targets. https://github.com/sbt/sbt-native-packager/pull/1310
Currently, Cloudflow relies on sbt-docker internally(e.g. the operator image) and for the
buildApp
task of the sbt plugin.This causes small issues, especially with caches, such as
buildApp
task needs to be run after aclean
when you change Cloudflow version (I can confirm that this is automatically solved by sbt-native-packager).Also
sbt-native-packager
is a more widely used and maintained project.Our dependency on
sbt-docker
is the extraction of the digest that can be replaced by something like:On the downside this is going to be a breaking change for the user.