podman push --all-tags

[SergeyBear]

/kind feature

Description

It would be very usefull to have '--all-tags' option for podman push, so to be able to push all image tags at once to remote registry.

Usecase: I'm building image from scratch and automatically tag local image with installed package version by build script. Then in separate CI job I'm testing image and if it's ok, I push it to remote registry. The problem is CI cannot know package version to use it as a tag in push job and without a tag podman push only latest image. Using whole build -> test -> push in single script makes it hard to maintain and using of CI/CD less usefull.

Steps to reproduce the issue:

buildah pull busybox
buildah tag busybox busybox:1.2.3

Describe the results you received:

podman push busybox docker://<remote_registry>/busybox
skopeo inspect docker://<remote_registry>/busybox
...
"RepoTags": [
        "latest"
    ],
...

Describe the results you expected:

podman push --all-tags busybox docker://<remote_registry>/busybox
skopeo inspect docker://<remote_registry>/busybox
...
"RepoTags": [
        "latest",
        "1.2.3"
    ],
...

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Version:       1.0.0
Go Version:    go1.11.4
Git Commit:    "49780a1cf10d572edc4e1ea3b8a8429ce391d47d"
Built:         Mon Jan 14 20:38:17 2019
OS/Arch:       linux/amd64

Output of podman info:

host:
  BuildahVersion: 1.6-dev
  Conmon:
    package: podman-1.0.0-1.git82e8011.fc29.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: 49780a1cf10d572edc4e1ea3b8a8429ce391d47d'
  Distribution:
    distribution: fedora
    version: "29"
  MemFree: 1689677824
  MemTotal: 2087301120
  OCIRuntime:
    package: runc-1.0.0-68.dev.git6635b4f.fc29.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: ef9132178ccc3d2775d4fb51f1e431f30cac1398-dirty
      spec: 1.0.1-dev
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 2
  hostname: fedora
  kernel: 4.20.8-200.fc29.x86_64
  os: linux
  rootless: true
  uptime: 1h 56m 14.06s (Approximately 0.04 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/gitlab-runner/.config/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/gitlab-runner/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
  ImageStore:
    number: 3
  RunRoot: /tmp/user/991

Additional environment details (AWS, VirtualBox, physical, etc.):
fedora 29

[rhatdan]

Tom could you look at this for buildah and then podman?

[TomSweeneyRedHat]

Yep, been thinking about it in the back of the noggin, shoulda grabbed this earlier.

[rhatdan]

Work is ongoing.

[rhatdan]

@TomSweeneyRedHat Tells me this has stalled, and potentially blocked altogether based on comments from @mtrmac

[nc-ruth]

@rhatdan do you know what the status of this feature is?

[rhatdan]

@TomSweeneyRedHat Could you give @nc-ruth and update and link to @mtrmac comments.

[TomSweeneyRedHat]

@nc-ruth please reference containers/buildah#1380 and look for the comments from @mtrmac. In summary, there were a number of issues with the approach that I attempted there. in addition to that, @mtrmac was concerned that we'd overly push images that the user was unaware of.

[nc-ruth]

Thanks for the links @TomSweeneyRedHat, and it does makes sense with @mtrmac 's concerns.
@rhatdan based on insights in containers/buildah#1380 this feature would be more hurtful than helpful 👍

Thank you.

[fabb]

Tom could you look at this for buildah and then podman?

@rhatdan could it be that it was never implemented for podman? With podman 4.1.1 in quay.io/podman/stable I still get this error:

# podman push --all-tags
Error: unknown flag: --all-tags
See 'podman push --help'

[mtrmac]

Just to link current status, see containers/common#1099 for another work on this area.

(I continue to be rather unimpressed by the need for the feature, but that’s neither here nor there.)

[cig0]

(I continue to be rather unimpressed by the need for the feature, but that’s neither here nor there.)

Really? I maintain the images we use to run our CI workloads. Right now, I need to push a new image with three tags: latest, $(date "+%Y-%m-%d-%H%M%S") and podman-4.4.2.

I'm curious about your workflows since you are rather genuinely unimpressed about people asking for this - arguably - quite a useful feature.

And yes, I read your rationale on containers/common#1099, and I believe it's a mistake to find excuses to avoid making a tool more ergonomic.

[mtrmac]

So you can, conveniently enough, list the exact three tags to push. Is not having to type that out really worth forever worrying about surprise outcomes, like someone running the build system on a system that has already pulled another image from the same repo (e.g. for debugging, or because it was left around from a build attempt of a previous version)? Even if that can’t happen now, are your systems documented and set up to ensure that it won’t ever happen after a significant future refactoring of the CI system?

My personal impression is that the trade-off of reliability vs. convenience just isn’t there, and that steering users towards being explicit is probably better long-term. Of course, users may decide for themselves the other choice would be better.

But combine that with that fairly long history of several people trying to implement this, and running into non-trivial implementation and especially semantic difficulties in defining what exactly should --all-tags do. The effort vs. user benefit just isn’t there in my personal judgement, so this is just not something I personally find attractive to work on vs. many other possible features.

Other people may well decide that this is a critical feature that must be done, and decide to work on it. I am “rather unimpressed” speaking only for myself, and I am not in charge of deciding what gets done in Podman at all.

[andrewleech]

FWIW I've just stumbled on this as a cli incompatibility with docker when trying to migrate to podman.

I build a lot of images in CI jobs where it always tags the image with the git sha, then optionally with latest if on main branch, and/or also tag the image with a git tag if there is one. Then push them --all-tags in one go.

Not having this compatible argument in podman means I have to go back and complicate the conditional checks in the build scripts to track which tags are needed for the push command.

I'm in the process of trying to roll out a migration from docker to podman company wide to support moving from docker+machine to kubernetes; extra complications in build scripts like this (minor one) makes it harder to sell the change!