[DISCUSSION] Handling multiple tags in v3

[PhrozenByte]

Is your feature request related to a problem? Please describe.

Ref #57

Describe the solution you'd like

v2.4 breaks pushing multiple tags by assuming that all tags reference the same digest (see #57). The first tag is assumed to be some sort of "primary" tag and all following tags are just "aliases". This apparently wasn't intended and needs fixing, but nevertheless, I actually like the idea - just not for a v2 release, but v3.

I remember when using redhat-actions/push-to-registry for the first time I actually assumed multiple tags to be aliases. This feels way more natural, especially when considering that the tags input supports fully qualified image names. If we assume tags: foo quay.io/my-user/my-image:bar as input I didn't expect that there needs to be a bar tag locally. This (false) interpretation (of mine) also matches how we'd use podman push: The first tag is the local tag (the first arg of podman push), all following tags are remote tags (subsequent args of podman push). Additionally, I don't really see a reason why we would expect the bar tag to exist locally for inputs like quay.io/my-user/my-image:bar. Anyhow, silently assuming the first tag to be the local one feels a bit hacky, too.

Thus I'd like to suggest to mimic podman push. There should be a separate, but optional input for the local image name (let's call it local). The existing registry, image and tags inputs can be interpreted just as in the current v2.4. The local input defaults to the value of image and the first tag in tags - and only this tag is required to exist locally. If the first tag in tags is a fully qualified image name, we bail (we shouldn't silently assume that a tag in a fully qualified image name exists locally).

I'd like to add that when using Buildah, images are commited with the latest tag by default. This is totally fine in build environments. But we don't necessarily want to push this image with the latest tag. Right now we have to add another step to our build scripts to additionally tag the digest with all the tags we want on our registry. IMO this is a superfluous step. By introducing a separate local input we can spare this step.

This

registry: quay.io/my-user
image: my-image
tags: foo my-other-image:bar quay.io/my-other-user/yet-another-image:latest

executes (as in v2.4)

podman push my-image:foo quay.io/my-user/my-image:foo
podman push my-image:foo quay.io/my-user/my-other-image:bar
podman push my-image:foo quay.io/my-other-user/yet-another-image:latest

This

tags: quay.io/my-user/my-image:foo quay.io/my-user/my-other-image:bar quay.io/my-other-user/yet-another-image:latest

results in a "no local tag to push given" error (we don't silently assume the tag of a fully qualified image name to exist locally).

This

local: working-image:latest
registry: quay.io/my-user
image: my-image
tags: foo my-other-image:bar quay.io/my-other-user/yet-another-image:latest

executes

podman push working-image:latest quay.io/my-user/my-image:foo
podman push working-image:latest quay.io/my-user/my-other-image:bar
podman push working-image:latest quay.io/my-other-user/yet-another-image:latest

This

local: working-image:latest
tags: quay.io/my-user/my-image:foo quay.io/my-user/my-other-image:bar quay.io/my-other-user/yet-another-image:latest

executes

podman push working-image:latest quay.io/my-user/my-image:foo
podman push working-image:latest quay.io/my-user/my-other-image:bar
podman push working-image:latest quay.io/my-other-user/yet-another-image:latest