Why does it create an <none> image?

[ghost]

steps

1. sbt docker:publishLocal

problem

There's a 703MB image named <none> that is created.

expectations

sbt-native-packager cleans after itself, so <none> is deleted if it's only used for prep work.

original bug report

Hi all

When I run the command:

sbt docker:publishLocal

it always create the following images:

sapmock             0.1                 db261ab225b5        8 hours ago         664MB
<none>              <none>              0940c75d8e5a        8 hours ago         703MB
openjdk             8                   bec43387959a        10 days ago         625MB

and I could not figure out, why it always create an <none> image.

I am using the latest version of sbt-native-packager and the build.sbt looks as the following:

enablePlugins(JavaServerAppPackaging)
enablePlugins(DockerPlugin)
dockerExposedPorts := Seq(8080)

OS is UBUNTU 18.04

What am I doing wrong?

Thanks

[eed3si9n]

See https://github.com/sbt/sbt-native-packager/releases/tag/v1.3.16.
I added multi-stage Docker build in #1190 (to change the file permission without fs layer overhead), so maybe it's that?

[vladimirshin]

+1, is there any progress on this issue?

[muuki88]

Thanks for asking @vladimirshin 😃 . I'm happy to give you guidance and merge pull requests if you would like to work on this issue 🤗

[yingding]

+1, do i need this image? is it safe to be deleted or is there any dependencies on that image?

[eed3si9n]

The image is used basically as a preparation kitchen to change your real image's file permissions. Without using the technique, it will double the final image size for no reason. If <none> is confusing, maybe we should try to name it or something, but I think it's a good technique, unless there are some other better technique to change permissions.

As far as I know, you should be able to delete it afterwards. Maybe that's something we can automate too.

[eed3si9n]

I rewrote the description of the bug. I hope @bifunctor won't mind.

[mkurz]

Please read my comment how this can easily be solved:

...Therefore I propose to add a config (like autoCleanupIntermediateImages) which makes the plugin remove those images after docker:publish... has finished (we can even turn it on by default).
The solution is very easy, we just need to label the created intermediate image and then remove images with this label:
moby/moby#34513 (comment)
I propose to add two labels, one specific one for that image, so we can remove exactly that image on build cleanup and one general label, in case autocleanup is disabled, someone can later still remove all intermediate images generated by the docker plugin by just filtering for that general label.

[muuki88]

@mkurz thanks for updating this. Would you like to try to make that change? 😃

[mkurz]

Yes I will. PR is coming soon.

[mkurz]

Pull request with the fix: #1279