Oh wow, didn't know that is possible tbh rofl

Did a quick research and found this page: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

In older versions of Docker, it was important that you minimized the number of layers in your images to ensure they were performant. The following features were added to reduce this limitation:
Only the instructions RUN, COPY, ADD create layers. Other instructions create temporary intermediate images, and do not increase the size of the build

So do we really have a benefit or is this just a local number of layers that is decreased without any impact to the final image anyways?

I was wondering this as well when I just stumbled upon this with a fellow student. After what you've posted, this does not actually add a performance benefit, but looking at https://hub.docker.com/layers/mailserver/docker-mailserver/edge/images/sha256-1caa65c0f7f85428a145922181093304b20baac57ca8afbdf4d0fa1115e031aa?context=explore for example, they do appear as a layer?

We don't need to merge this at all, I just looked at the link above and thought: "Hey, maybe we can reduce layers here :)"

Then this might be more a "style" question. Imho i see no problem with all ENV and LABEL to appear as a single layer on dockerhub although there is no change in fact.

Is this possible for ARG as well?

Then this might be more a "style" question. Imho i see no problem with all ENV and LABEL to appear as a single layer on dockerhub although there is no change in fact.

Is this possible for ARG as well?

You can apparently not do this for ARG. I had no problem with the style as is, but my fellow said he knows using \ to concatenate the LABEL and ENV command to be good style.

I will merge #1989 first when CI passes, then I will merge this PR and then announce the feature freeze in the maintainers discussion 🎉

I think, this is just a docker hub thing. LABEL, ENV etc. do not add additional layers. They just end up in the manifest.

You can verify this for example with dive. Or take a look at how many layers are pulled with docker pull. There will be no difference after this merge.

I don't open the style discussion 😄 That is just personal preference, if you prefer \ syntax. What I do for example from time to time is grep ENV Dockerfile to get all ENVs. That would not be possible anymore (in that easy form). No show-stopper. My preference would be to leave it as it is.

I think, this is just a docker hub thing. LABEL, ENV etc. do not add additional layers. They just end up in the manifest.

You can verify this for example with dive. Or take a look at how many layers are pulled with docker pull. There will be no difference after this merge.

I don't open the style discussion smile That is just personal preference, if you prefer \ syntax. What I do for example from time to time is grep ENV Dockerfile to get all ENVs. That would not be possible anymore (in that easy form). No show-stopper. My preference would be to leave it as it is.

I understand. As this was started as a real improvement when it comes to layer count, but now only is a style thing. I will close this:) I actually prefer the way it is ATM over this PR, but I figured in the beginning if there was a real benefit, it would be worth it.

Feature freeze is now active :D

What I do, to ultimately "optimize" the layer count to 1:

FROM docker.io/debian:buster-slim as build
[..]
# build final image
FROM scratch
COPY --from=build / /

The only disadvantage of this approach is, that you lose the ability to use a base-image (debian). Now you have one image (1 layer) without dependency to an upstream image (debian).