universal:publish(ZIP) when combined with Sonatype Nexus? Running
universal:packageBintakes roughly 40 seconds for our codebase,
universal:publishLocalabout 90 seconds, while
universal:publishto Nexus takes... 30 minutes and more :sweat_smile: Even for fresh local Nexus 3.30.0 setup. Meanwhile, sbt-assembly works just fine. It takes about 17 minutes, but it's mostly build/packaging time (fat JAR creation can be - obviously - quite time consuming) - publish finishes quickly
[info] Total time: 2063896 ms [info] moduleA / Universal / publish : 1254785 ms [info] moduleB / Universal / publish : 1239656 ms [info] moduleC / Universal / publish : 1207546 ms (...) [info] moduleA / Universal / packageBin : 9804 ms [info] moduleB / Universal / packageBin : 9713 ms (...) [info] moduleA / packageOptions : 1257 ms [info] moduleB / packageOptions : 1214 ms (...)
@falconepl, at least we now know that the bulk of the time is taken by the
publish itself, rather than by building/packaging. This is progress. Next thing would be to
jstack the SBT process in the middle of publishing, and figure out where exactly it gets stuck (look for stack frames in
Also, AFAIK, sbt-native-packager doesn't do much with the
publish task. Does the same issue pop up when you do
Compile / publish, or does this only happen with
Universal / publish?
Finally, I imagine the packaging process shouldn't include much logic that would lock up like this. An obvious culprit would be the Nexus itself - although I'm not sure why this might be the case. Might be something weird - like you're publishing to a repository group rather than to a repository. If you can publish to your Nexus instance using raw HTTP (bad practice), then you may want to sniff that traffic (using WireShark and the like), and look for abnormalities in it (e.g. extremely long response times, large number of requests and so on).
mymodule/docker:publishLocalmultiple times? I mean
<none>images that are not pruned even if the Docker image tag remains the same:
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE my-image dev-SNAPSHOT c927fa471f18 6 seconds ago 740MB my-image latest c927fa471f18 6 seconds ago 740MB <none> <none> 7a46221591b3 3 minutes ago 740MB <none> <none> 6e7c34fdb71d 4 minutes ago 740MB
dockerAutoremoveMultiStageIntermediateImagesis set to
trueby default - however, it seems that it's not taken into account
Without such auto-removal, something like:
docker rmi `docker images -f "dangling=true" -q`
is needed to prune those dangling images
FYI - I solved this issue by adding a custom label to every Docker image created with sbt-native-packager (via
build.sbt) and then by adding:
docker rmi $( docker images \ --filter "label=com.acme.docker-image=my-module" \ --filter "dangling=true" \ --quiet )
to the script that's responsible for Docker-related setup in my project
DockerPluginis about building a
Dockerfileand the corresponding build context - and that should be more or less the same for all Docker build tools (I think). This can be factored out into a separate plugin (
DockerBuildContextPluginor whatever). You'll have to reimplement building, publishing (including local) and cleaning - but that should be doable if you're familiar with the tool you're wrapping.
Containerfileinstead (not a big deal now as it seems most tools read the
Dockerfileas is as well). The trickiest bit seems to be the fact that each tool seems to come with its own fancy features. It seems that
podmancould be the simplest one to adopt (it's daemon-less and the command line is pretty much the same as Docker) but wondering that, if deciding on splitting the logic in the
DockerPluginif maybe the best approach is to have something like a
ContainerPackagingarchetype that generates the
Containerfile) and then the actual tool wrapper plugin (i.e.
The trickiest bit seems to be the fact that each tool seems to come with its own fancy features.
I'll take your word for it, since I haven't really dug into those tools. But
Dockerfile support seems to be standard enough to warrant reuse.
archetype that generates the Dockerfile
Yes, that's what I meant with
DockerBuildContextPlugin (same as your
ContainerPackaging if I understood correctly).
Thanks @TheCodingPenguin / @andrewgee
I haven't noticed that bintray is going down?! https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/
Essentially sbt-native-packager is published to a general purpose sbt plugins repository maintained by sbt itself.
So sbt-native-packager will move wherever sbt will move.
publishor similar) rather than
Docker / publish. The error log probably has more details - most importantly the name of the failing task.
org, it should be there but nothing. https://repo1.maven.org/maven2/com/typesafe/sbt/
hi all !
I ran into a problem while making a docker image with
sbt native packaer docker plugin.
My docker image internally writes the log in
demiourgos728 user does not have write permission in
So, an AccessDinied error occurs.
How can I add permissions?
spark-submit. I think it is achievable through configuration, but is there an already "best" way to do it ?
Hello , following https://www.scala-sbt.org/sbt-native-packager/formats/windows.html , i try to build an MSI package. I did it eventually but i don't get why my first try did not work. I have a multi project SBT build def and i have set the maintainer key at the begining of the file with
ThisBuild / Windows / maintainer := "TOTO"
It does not work. BUt if i put :
.settings( Windows/maintainer := "TOTO", )
On the relevant project, then it works properly and i get my package.
I have inspected the key to look at delegation order.
I don't understand. I think i have an issue with scope but i don't get whet it is.
Thank for your feedback.
maintainerat the project level: https://github.com/sbt/sbt-native-packager/blob/2268343362812bbca6e49f15e05586821a101bc7/src/main/scala/com/typesafe/sbt/PackagerPlugin.scala#L95. Any settings with a larger scope (
ThisBuild / maintainer,
Global / maintainer) are overridden by this setting.