multiple tags in a single yml file

[glennc]

In a single repo I want to setup multiple tags pointing to the same few base images. Something like this:

image: glennc/dotnet:1.1-runtime
manifests:
  -
    image: microsoft/dotnet:1.1.0-runtime
    platform:
      architecture: amd64
      os: linux
  -
    image: glennc/dotnet:1.1.0-runtime-nanoserver
    platform:
      architecture: amd64
      os: windows
image: glennc/dotnet:1.1-sdk
manifests:
  -
    image: glennc/dotnet:1.1.0-sdk-msbuild-rc4
    platform:
      architecture: amd64
      os: linux
  -
    image: glennc/dotnet:1.1.0-sdk-msbuild-rc4-nanoserver
    platform:
      architecture: amd64
      os: windows

Is there a YAML format I am missing that would make this possible? Seems like I would need many different files to make it work right now. If there is no good way to do it I could propose some formats we would accept and do a PR. Though my Go skills are weak so it might be a painful PR process to begin with :).

[tianon]

I don't think manifest-tool supports/uses them now, but "documents" could be used for this type of functionality (http://www.yaml.org/spec/1.2/spec.html#id2760395):

image: ...
manifests:
  ...

---

image: ...
manifests:
  ...

[glennc]

Yeah, makes total sense to use that as the way to support it.

[tianon]

(A closely related feature I'd like is the ability to specify more than one image in the image: line so that the same exact manifest object can be pushed twice without having manifest-tool repeat the work of looking up the images it needs to push and potentially getting a different answer on subsequent tries, but I'll open a separate issue for that if @estesp tells me to 😇)

[glennc]

I was going to bring up the same thing in this issue depending on how the conversation went :).

[nucleardreamer]

Yes please! This would be extremely helpful

[glennc]

I am good with working through a PR, but I didn't want to start the effort if @estesp didn't want it.

[estesp]

@glennc I'm fine with that--sounds reasonable!

@tianon so basically you are looking for what effectively is a "tagging" option where instead of being limited to one tag on the target you want to be able to tag it with multiple tags, which effectively is another push (and I get you don't want to be redoing the lookups on the dependent images to effectively only be doing an additional tag operation) This came up in a recent conversation--that no other tools (other than something that interacts with manifest list entries) can tag your manifest list manifest object/sha, because the docker tag command only operates on a resolved image, which will be one subentry inside a manifest list. Anyway, I'm definitely fine looking for a way to support this. We could additionally add a 'manifest-tool tag' command as another option.

[tianon]

@estesp yeah -- I've got a group of images from multiple architectures which I need joined into a manifest list, and that final manifest list needs to be pushed to several tags on the Hub / registry

For example, in the case of the busybox official image (ignoring that it has more than one variant for just a moment), I'd need to create busybox:1.26.2, busybox:1.26, busybox:1, and busybox:latest which all point to the same single manifest list (and it'd be really lovely if I could push that in such a way that the same object gets pushed to all four tags and thus has the same digest).

[glennc]

I have the exact same scenario with our images. 1.0.3, 1.0, 1 not an uncommon pattern.

[tianon]

Friendly poke @estesp 🙏 😇 ❤️

[tianon]

This is actually even more of a problem than I first thought, since it needs to "mount" all the blobs of all the layers of all the images being included, which takes a significant amount of time (and in the case of the alias tag pushes, is 100% duplicate work).

[tianon]

(On the plus side, though, it appears that pushing the exact same list of images twice results in the same digest, so at least there's that! 🤘)

[estesp]

Yes.. somehow this missed my radar for that release I made last week. Let me think about how to represent additional tags in the yaml, as it really should be a different "action" (pretty sure I can tag the final digest using the registry API rather than acting like it is another push which will give you a huge speedup)

[estesp]

I just realized the PR I have created deals with @tianon's use case but maybe not the originator's (@glennc)?

The new feature in the YAML input is, after specifying the target image: ... you can now specify a list of tags like:

tags: [1.8.3,1.8,1.8-alpine,06142017-build]

And the manifest list created by the rest of the YAML spec will be tagged with the default tag ("latest") or the one specified in the image: ... specifier, and then additionally will tag that same manifest with the list of tags from the tags: ... specifier.

If that doesn't solve the original issue @glennc let me know! Of course @tianon will be happy either way :)