Reason to have "name" label?

[mfojtik]

What is the reason to have the name label if it matches with the image name? Both OS and Kubernetes have display-name label which provides more information in human-readable form about the image content. For example: https://github.com/openshift/sti-ruby/blob/master/2.2/Dockerfile#L13

[TomasTomecek]

We use this in build service to construct image name. Name of dist-git repo is different from name label b/c label may contain slashes. Also you may obtain an image as an archive and it's good to know its desired name and origin.

[mfojtik]

@TomasTomecek how do then set the "name" label when doing Docker build? How is that different from tagging the image with that name?

[TomasTomecek]

Here's the workflow:

1. Create dockerfile; set name, version, release labels by hand
2. Submit build
3. Koji constructs NVR of the build from labels like this: ${com.redhat.component}-${name}-${version} (don't ask, it's the way koji works)
4. build the image using some ugly name (we want to change this so the name is prettier)
5. tag the built image using name, version, release labels and push it to registry

This can be changed/updated of course. It's just what we use now.

[mfojtik]

@TomasTomecek when you tagging the image, can you change the image name instead of adding the name tag? I think I understand the use-case you have, but that label seems redundant to me long term.

[TomasTomecek]

I think there is slight misunderstanding here: without name, version, release labels, build system has no idea how to name/tag the image. The only information it has at that time is com.redhat.component label which is name of component within bugzilla, e.g. rhel-server-docker and that is for images named rhel{6,7}.

So, we could get rid of the label, but we would have to find new way how to get final image name. Basically a mapping between com.redhat.component, branch within git and the final image name.