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.
when i add this:
graalVMNativeImageGraalVersion := Some("19.1.1")
to my build.sbt it does not find the docker container
when i add this
containerBuildImage := Some("graalvm/graalvm-ce:21.1.0")
[warn] multiple main classes detected: run 'show discoveredMainClasses' to see the list [error] stack trace is suppressed; run last Graalvm-native-image / packageBin for the full output [error] (Graalvm-native-image / packageBin) Could not find a main class. [error] Total time: 0 s, completed 18.06.2021 15:11:32
what am i doing wrong?
/home/X/Projects/X/build.sbt:32: error: type mismatch; found : sbt.Def.Initialize[sbt.Task[Option[String]]] required: Option[String] containerBuildImage := GraalVMNativeImagePlugin.generateContainerBuildImage("ghcr.io/graalvm/graalvm-ce:latest")