Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Przemek Sokół
    @falconepl
    It would be great to see an upload speed and a progress bar in sbt when publishing artifacts - that would be especially useful for large uploads. What do you think?
    Dmitry Polienko
    @nigredo-tori
    @falconepl, it hasn't been an issue for me, so I don't really have an opinion. But there's an issue (sbt/sbt#5627) in the SBT repo that you can vote for.
    Przemek Sokół
    @falconepl
    @nigredo-tori Thanks for the link
    Manu Zhang
    @manuzhang
    Hi all, with the AutoPlugin approach to set different build envs through system properties, I find the property is required even for a sub-project that hasn't enabled the plugin. Is there a way to work around it ?
    Dmitry Polienko
    @nigredo-tori
    @manuzhang, if you only use buildEnv inside the AutoPlugin that you've created, then I don't see how that would be possible. Could you share your AutoPlugin source and/or error message (possibly redacted)?
    Przemek Sokół
    @falconepl
    Hi there! Do you know if it's possible to get rid of dangling Docker images when running mymodule/docker:publishLocal multiple 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
    I can see that dockerAutoremoveMultiStageIntermediateImages is set to true by default - however, it seems that it's not taken into account
    Przemek Sokół
    @falconepl
    Also - what I can see is that sbt/sbt-native-packager#1229 is a related issue, but it looks like is should be address by very dockerAutoremoveMultiStageIntermediateImages

    Without such auto-removal, something like:

    docker rmi `docker images -f "dangling=true" -q`

    is needed to prune those dangling images

    Przemek Sokół
    @falconepl

    FYI - I solved this issue by adding a custom label to every Docker image created with sbt-native-packager (via dockerLabels in 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

    A. Alonso Dominguez
    @alonsodomin
    hello all, I think this has been asked before but didn't go anywhere. We use a CI/CD that is deployed in Kubernetes and since in Kubernetes version 1.19.x Docker is no longer supported, I was wondering if there are any plans on supporting alternative tools to build container images (i.e. docker buildx, img, kaniko, etc)
    Dmitry Polienko
    @nigredo-tori
    @alonsodomin, there's an issue open for Kaniko: sbt/sbt-native-packager#1173 . From my limited understanding, it shouldn't be terribly hard to implement. The bulk of DockerPlugin is about building a Dockerfile and 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 (DockerBuildContextPlugin or 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.
    A. Alonso Dominguez
    @alonsodomin
    @nigredo-tori yeah, the Dockerfile should be compatible across different tools, although apparently the trend is to start naming them Containerfile instead (not a big deal now as it seems most tools read the Dockerfile as 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 podman could 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 DockerPlugin if maybe the best approach is to have something like a ContainerPackaging archetype that generates the Dockerfile (or Containerfile) and then the actual tool wrapper plugin (i.e. DockerPlugin, PodmanPlugin, etc)
    Dmitry Polienko
    @nigredo-tori

    @alonsodomin,

    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).

    Artavazd Balaian
    @REASY
    Hello. Is there a way to tell to the Native Packager plugin to put last modified date to the resource in created JAR? I've checked https://github.com/sbt/sbt-native-packager/blob/1.1.x/src/main/scala/com/typesafe/sbt/packager/universal/UniversalPlugin.scala and https://github.com/sbt/sbt-native-packager/blob/1.1.x/src/main/scala/com/typesafe/sbt/packager/universal/Archives.scala, but didn't see anything. Currently it creates an entry with default date = 1 January 1970
    Artavazd Balaian
    @REASY
    @wsargent in #playframework channel helped with above issue. It's related to SBT: playframework/playframework#10572
    CodingPenguin
    @TheCodingPenguin
    Maybe I missed the conversation but is sbt-native-packager only hosted in Bintray ? If so what's the future plan for it ?
    Andrew Gee
    @andrewgee
    I have a similar question to @TheCodingPenguin. Seems that native packager is currently unavailable because it's hosted in Bintray, and there's a "brown-out" underway today to warn us it won't be available after this month
    Anything we can do to help move it?
    Nepomuk Seiler
    @muuki88

    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.

    Andrew Gee
    @andrewgee
    Thanks @muuki88. I wonder if this affects other parts of sbt as well then today
    Nepomuk Seiler
    @muuki88
    Andrew Gee
    @andrewgee
    thanks
    Nicholas Molenaar
    @nmolenaar_gitlab
    Hey guys, I keep getting the error: "(publishConfiguration) Repository for publishing is not specified." while I have a repository defined in my build.sbt and I did my docker login command.
    dockerRepository := Some(".....")
    Any one knows what the problem maybe?
    Dmitry Polienko
    @nigredo-tori
    @nmolenaar_gitlab, this is SBT's error message (rather than sbt-native-packager's), which means you are somehow running standard publishing task (publish or similar) rather than Docker / publish. The error log probably has more details - most importantly the name of the failing task.
    Yannick Koehler
    @ykoehler
    Hi, is there a way to connect docker:publishLocal with the sbt-docker instead of the internal sbt-native-packager/docker plugin?
    leo-ersagun
    @leo-ersagun
    Hi all sbt-native-packager is just disappeared from mvn is this normal? Is there any other place where I can find ? thanks in advance
    Eric K Richardson
    @ekrich
    I was just looking and from the sbt file org, it should be there but nothing. https://repo1.maven.org/maven2/com/typesafe/sbt/
    Docs show that org too.
    Eric K Richardson
    @ekrich
    leo-ersagun
    @leo-ersagun
    Thanks @ekrich I will do it
    Eric K Richardson
    @ekrich
    :thumbsup:
    heesuk-ahn
    @heesuk-ahn

    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 /opt/docker/results.

    However, the demiourgos728 user does not have write permission in /opt/docker.

    So, an AccessDinied error occurs.

    How can I add permissions?

    Jonathan Weaver
    @jweaver-personal
    Is there any resolution to sbt-native-packager not being available on the jfrog repo yet?
    Alexis BRENON
    @AlexisBRENON
    Hi all !
    Is there an recipe to package a Spark application with Docker ?
    I use the bitnami/spark base image, but the "classical" entrypoint (calling "java") is not well suited. Best solution would be to call spark-submit. I think it is achievable through configuration, but is there an already "best" way to do it ?
    Alexis BRENON
    @AlexisBRENON
    Is there also a way to avoid to publish the jar while publishing the docker image ?
    1 reply
    Nicholas Molenaar
    @nmolenaar_gitlab
    @AlexisBRENON so you would only like to publish the docker image and not the JAR file?
    dduquesne
    @dduquesne

    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.

    Dmitry Polienko
    @nigredo-tori
    PackagerPlugin sets maintainer at 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.
    DarkWingMcQuack
    @DarkWingMcQuack
    hey everybody i want to use graalvm with this project, using a docker container to build the graalvm package

    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")

    i get

    [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

    when running sbt graalvm-native-image:packageBin

    DarkWingMcQuack
    @DarkWingMcQuack
    /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")
    what am i doing wrong?
    DarkWingMcQuack
    @DarkWingMcQuack
    is it not possible to use the graalvm packager with multiple main classes?
    Peter Storm
    @peterstorm
    Is it possible to tag the docker image you create with native-packager with a version from sbt-dynver? Haven't really found anything in the docs mentioning tags :(
    peterstorm
    @peterstorm:matrix.org
    [m]
    I think I figured it out.
    Next question :D Can I publish to a private docker repo?
    Oh, is it just through your docker daemon?