Skip to content

Reason to have "name" label? #48

Open

Description

@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

Activity

  1. TomasTomecek commented on Sep 17, 2015

    @TomasTomecek
    Contributor

    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.

  2. mfojtik commented on Sep 17, 2015

    @mfojtik
    Author

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

  3. TomasTomecek commented on Sep 17, 2015

    @TomasTomecek
    Contributor

    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.

  4. mfojtik commented on Sep 17, 2015

    @mfojtik
    Author

    @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.

  5. TomasTomecek commented on Sep 17, 2015

    @TomasTomecek
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions