[feature] Add TAG to Dockerfile

[ivan1986]

Add instruction TAG with same behavion as build -t option

This allows you to keep the information on the name of the image file instead of building the script and making it easier to to find a file of this image.

[vdemeester]

@ivan1986 This is a duplicate of #5603 I think. See this too : #886.
This has already been discussed in the past, but I'll let this open for now to get input from other people and maintainers 😉.

[ivan1986]

@vdemeester hm, how i see many need this feature :)

and also - main argument about override
build -t override tag too, and not produce error

[jakirkham]

Sorry, not sure I like it. We don't name images in Dockerfiles and I don't think we should fix the tag either. Often these are tracked in git or other vcs were tags can be added to provide the same level of information about the Dockerfile. That is just my opinion though.

[alxrcs]

I really think you should consider this feature. I'd like to be able to clone a Git repo, and be able to do docker build . without having to worry about consistently naming my images. Who's better than the image authors to decide on a default name?

If collisions exist, you could always issue a warning or something, right?

[untoreh]

since each run command creates a layer, the ability to tag after each layer would make it more practical to create pyramid-like images

[VelorumS]

We have to be able to get the tag information from the building process. How are you getting versions from apt/dpkg into tags?

[richard-fairthorne]

There's a lot of debate on this feature. I would like it. In the meantime, I've developed a workaround for unix like OS's, or sh users.

#!hb-path docker -t somecompany/sometag
FROM ubuntu:16.04
[...]

Requires my hb-path wrapper script. Make Dockerfiles executable. If you wish to use a different tag, just run Docker the normal way.

https://github.com/richard-fairthorne/hb-helpers

[jusdino]

I especially like this idea.

If I'm going to share an entire source package for an application that uses multiple containers and a single docker-compose.yaml file and if, for whatever reason, I can't make containers directly available, having the default tag names baked right into the Dockerfile would make having someone else building and testing the full application much easier since the tester wouldn't have to interpret the docker-compose.yaml and then deduce which container is intended to correspond to each container name/tag referenced in the file. They would just build each container with default tags and then fire up the full application!

[thaJeztah]

Let me close this one, as it went stale, and the Dockerfile syntax is now maintained in https://github.com/moby/buildkit