I m going over s new docs for the

Question

I m going over < curved television 6568> s new docs for the docker publishing functionality and it occurs to me that there is a bit of a terminology mismatch But I might be wrong because I don t use Docker daily so bringing it up here for discussion

happy-kitchen-89482 · Answer

AFAICT Docker has two concepts Repository and Tag

happy-kitchen-89482 · Answer

For example `postgresql` is a repository and `13 4` is a tag within that repository

happy-kitchen-89482 · Answer

We have introduced repository image name and tag

happy-kitchen-89482 · Answer

our tag is the same as Docker tag so let s put that to one side

happy-kitchen-89482 · Answer

We I think combine our repository and image name into ` lt repository gt lt image name gt ` and this is used as the Docker repository concept

happy-kitchen-89482 · Answer

Am I understanding correctly

happy-kitchen-89482 · Answer

And assuming so what is the purpose of this Does this match how people use the `repository` in practice

happy-kitchen-89482 · Answer

I m thinking we should clarify our own terminology to match Docker s

happy-kitchen-89482 · Answer

Or even simplify and get rid of the two part naming

curved-television-6568 · Answer

+1 for simplifying In the Docker space you really only have the image tag which is made up of a name part and a tag part used as version defaults to latest separated with a colon And yes I think this concept isn t super clear either but is what it is for historical reasons I suppose The name part then has parts each separated with a slash What these parts mean is not dictated by Docker but a common concept is to have repository name while Docker hub have username repo

curved-television-6568 · Answer

Given the name template we could probably get rid of the repository field or perhaps just find better names for the various parts

curved-television-6568 · Answer

Would be happy to get more input from other Docker users here to hear their take on this

ambitious-actor-36781 · Answer

i think things get more confusing as there s also a registry the storage location so for `` `` is the registry `` is the repository `123` is the tag and you can have an infinite combinations of each all pointing to a single image

ambitious-actor-36781 · Answer

and really when building do you want to use the full `FROM <http eu gcr io mycompany base 123|eu gcr io mycompany base 123>` in all your dockerfiles I think it s pretty common to do `ARG registry= mycompany FROM $ registry base 123`

worried-salesclerk-37834 · Answer

I think a field called image tags may be sufficient That s how the docker podman api works for build already right No need to try and interpret what those tags may mean On the other hand it could make bumping versions more of a hassle

happy-kitchen-89482 · Answer

So < curved television 6568> how do you feel about getting rid of the target level distinction between name and repository and just having repository which defaults to path to target name but can be overridden

curved-television-6568 · Answer

< ambitious actor 36781> yea that ll work with the build args Exactly how we do it too

curved-television-6568 · Answer

< happy kitchen 89482> yep I can get rid of the `image name` field I think there s enough flexibility already with the name template option

curved-television-6568 · Answer

< worried salesclerk 37834> agree we should not try to interpret anything or not too much at least At the same time offer constructs to support keeping the BUILD files DRY so I think we need to do some assembling of the image tag

happy-kitchen-89482 · Answer

Great so I ll hold off on more document review until that s done

curved-television-6568 · Answer

Hopefully improved the situation with this PR <https github com pantsbuild pants pull 13225>