Open mfojtik opened 8 years ago
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.
@TomasTomecek how do then set the "name" label when doing Docker build? How is that different from tagging the image with that name?
Here's the workflow:
name
, version
, release
labels by hand${com.redhat.component}-${name}-${version}
(don't ask, it's the way koji works)name
, version
, release
labels and push it to registryThis can be changed/updated of course. It's just what we use now.
@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.
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.
What is the reason to have the
name
label if it matches with the image name? Both OS and Kubernetes havedisplay-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