search tags in reverse order #26338

arsenalzp · 2025-06-10T19:32:38Z

This PR is intended to implement feature requested in issue #26053

As tags list might be either in ascending or descending order I decided to use boolean option --reverse-order instead of --order=newest and --order=older.

The option --reverse-order is meaningful by itself.

Does this PR introduce a user-facing change?

None

openshift-ci · 2025-06-10T19:32:43Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: arsenalzp
Once this PR has been reviewed and has the lgtm label, please assign tomsweeneyredhat for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Signed-off-by: Oleksandr Krutko <[email protected]> improve man page, remove duplicated import Signed-off-by: Oleksandr Krutko <[email protected]>

packit-as-a-service · 2025-06-10T20:50:40Z

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

baude · 2025-06-11T01:38:19Z

please add a release note to this ... it is currently None

baude · 2025-06-11T01:41:58Z

test/e2e/search_test.go

@@ -101,6 +103,26 @@ registries = []`
 		}
 	})

+	It("podman search list tags in reverse order", func() {
+		searchAscending := podmanTest.Podman([]string{"search", "--list-tags", ALPINE})


consider podmanTest.PodmanExitCleanly for this call and the next. You can then eliminate 109-12.

baude · 2025-06-11T01:44:11Z

docs/source/markdown/podman-search.1.md.in

@@ -91,6 +91,10 @@ The result contains the Image name and its tag, one line for every tag associate

 Do not truncate the output (default *false*).

+#### **--reverse-order**
+
+List tags in reverse order. Default is false.


instead of reverse order as a description, can you describe it in terms of time like you did in your commit?

Luap99 · 2025-06-11T08:48:13Z

Bool options don't scale well, what when the next person likes it sorted in a different way?
I think sticking with --sort= is best because that also aligns with other commands such as podman ps.

Also looking at the code I don't think any sorting is guaranteed whatsoever currently. So the assumption that it is sorted today is somewhat wrong. The code returns the results in the order the registry returned it AFAICT so it relies on the implemenation details of each registry and I doubt the image spec would have that defined in any way.
@mtrmac might know more abut that

So in short if we do like to have the option to sort then we must have the option to sort in both orders

arsenalzp · 2025-06-11T10:49:51Z

Bool options don't scale well, what when the next person likes it sorted in a different way? I think sticking with --sort= is best because that also aligns with other commands such as podman ps.

Also looking at the code I don't think any sorting is guaranteed whatsoever currently. So the assumption that it is sorted today is somewhat wrong. The code returns the results in the order the registry returned it AFAICT so it relies on the implemenation details of each registry and I doubt the image spec would have that defined in any way. @mtrmac might know more abut that

So in short if we do like to have the option to sort then we must have the option to sort in both orders

Hello,
I didn't know search return is non-Idempotent and depends on registries implementation.
So, two way sort (ascending, descending) does make sense here. I will rewrite code and related test.

mtrmac · 2025-06-11T11:29:12Z

First, let’s talk about how this does not implement #26053 : that asks for “newest” tags, not “alphabetically latest” tags.

I suspect the issue asked for “tagged latest”, i.e. “sort by time, return the most recently tagged one”. That’s outright impossible, “when was the tag added” is not a part of the registry API. (I suppose it would be possible to inspect each individual image and try to figure out when it was built, but that’s not the same thing.
Alternatively, the issue might have meant “numerically latest version”, and this clearly does not do that, because 9 < 10, but "10" < "9". The definition of “latest version” is unclear, because there is no universal standard for version number formatting, and the tag has no format defined (so it might be SemVer but pretty frequently is not).

But, the most important part is that the whole idea of #26053 is badly targeted: If the goal is to list the latest tag, that should use a “list tags in a repo” API, not an ill-defined “registry search with no defined semantics” API. Registries can, and do, limit the number of results. So, the latest tag might not be in the list at all!

My first recommendation is to use skopeo list-tags in a pipeline with a custom sorting command which precisely implements “latest” ordering as defined for that repo. Maybe we could do better, I’m not sure, but the whole requested use case of #26053 is clearly worse.

The code returns the results in the order the registry returned

Yes: The order, and the subset the registry chose to return.

mtrmac · 2025-06-11T11:35:21Z

But, the most important part is that the whole idea of #26053 is badly targeted: If the goal is to list the latest tag, that should use a “list tags in a repo” API, not an ill-defined “registry search with no defined semantics” API. Registries can, and do, limit the number of results. So, the latest tag might not be in the list at all!

Oops, podman search --list-tags actually is not a search at all, it is the “list tags in a repo” call. … But it, by default, limits the returned tags to an arbitrary subset of 25, and there seems to be no convenient way to return all of them (--limit 99999999999 I suppose).

arsenalzp · 2025-06-11T12:01:33Z

But, the most important part is that the whole idea of #26053 is badly targeted: If the goal is to list the latest tag, that should use a “list tags in a repo” API, not an ill-defined “registry search with no defined semantics” API. Registries can, and do, limit the number of results. So, the latest tag might not be in the list at all!

Oops, podman search --list-tags actually is not a search at all, it is the “list tags in a repo” call. … But it, by default, limits the returned tags to an arbitrary subset of 25, and there seems to be no convenient way to return all of them (--limit 99999999999 I suppose).

So, what it the decision for this particular issue? Should it be closed?

mtrmac · 2025-06-11T12:03:18Z

I’m leaning towards closing (as long as piping the output of podman to a separate sorting tool is convenient enough), but let’s see what others think.

Luap99 · 2025-06-11T14:11:10Z

Maybe @justin-octo can clarify on the exact request based on the points above.

But yeah logically one can do podman search --format {{.Tag}} --list-tags $IMAGE and the pipe that to whatever sorting command they like.

If the ask is just sorting by string asc/desc like this PR then I would not object to adding it but adding more complex stuff such as semver parsing seems out of scope to me.

justin-octo · 2025-06-11T17:43:36Z

So, the primary goal is to be able to easily identify the image tagged with the version number where the image is the same as the one tagged "latest". I currently do this by eyeball on the Docker Hub web site.
For example:
The current RedHat ubi9 image tagged "latest" has a digest of "591ff7bcd63f"
I currently visually scroll down to find the tag matching that digest that shows the full version number. In this case, it is tag "9.6-1749542372"

Being able to sort "pushed date" by most recent would allow me to do this from podman search, rather than having to go to the Docker Hub (or other registry) web site.

Hopefully that makes sense.

If there is some better way to do this, I'm all ears? But also, being able to sort by the "pushed date" would be useful as you all mentioned above.

justin-octo · 2025-06-11T17:55:55Z

When I do:

podman search --format {{.Tag}} --list-tags docker.io/redhat/ubi9

I only get the first 26 Tags (oldest from what I can tell). If I read above correctly, this order is determined by the registry. So, obviously, if there are hundreds of tags, I'm going to have to "page" all the way to the end to find the newest tags.

This seems like a lot of wasted data if all I want is the 25 newest tags. So, being able to reverse that sort order is what I was hoping for. And get the 25 newest, instead of the 25 oldest (or list them all, and then deal with hundreds of lines and multiple pages).

mtrmac · 2025-06-12T07:16:18Z

So, the primary goal is to be able to easily identify the image tagged with the version number where the image is the same as the one tagged "latest".

That would be interesting but the vendor-neutral registry protocol has no support for looking up tags by images (by digests). The code would have to fetch the manifest for each tag, as one HTTP request per tag.

It’s software that could be written but it’s such a number of requests, especially in the worst cases, that I don’t think this should be available as a convenient option. Of course it can be scripted using skopeo list-tags and skopeo inspect, but I think we need to steer users to different workflows.

Presumably the author of the image knows which image is the latest, and can provide that information using some other channel than a registry. Or maybe that specific registry implementation has its own private API that exposes something relevant.

Being able to sort "pushed date" by most recent

That would also be interesting, and it’s, again, not something available in the vendor-neutral registry protocol.

kolyshkin

If the searchReport is already sorted, then you can just reverse it.
Your commit message says "remove duplicated import" and I'm not sure what this refers to.

arsenalzp · 2025-06-13T06:54:20Z

If the searchReport is already sorted, then you can just reverse it.

Yes, I did reverse.

2. Your commit message says "remove duplicated import" and I'm not sure what this refers to.

I added another package import with different alias, it was removed.

By the way there is no decision if introduced changes are needed. I guess this PR will be closed.

openshift-ci bot added the release-note-none label Jun 10, 2025

search tags in reverse order

f719949

Signed-off-by: Oleksandr Krutko <[email protected]> improve man page, remove duplicated import Signed-off-by: Oleksandr Krutko <[email protected]>

arsenalzp force-pushed the issue_26053 branch from 31f479a to f719949 Compare June 10, 2025 20:00

baude reviewed Jun 11, 2025

View reviewed changes

kolyshkin reviewed Jun 12, 2025

View reviewed changes

search tags in reverse order #26338

Are you sure you want to change the base?

search tags in reverse order #26338

Uh oh!

Conversation

arsenalzp commented Jun 10, 2025

Does this PR introduce a user-facing change?

Uh oh!

openshift-ci bot commented Jun 10, 2025

Uh oh!

packit-as-a-service bot commented Jun 10, 2025

Uh oh!

baude commented Jun 11, 2025

Uh oh!

baude Jun 11, 2025

Choose a reason for hiding this comment

Uh oh!

baude Jun 11, 2025

Choose a reason for hiding this comment

Uh oh!

Luap99 commented Jun 11, 2025

Uh oh!

arsenalzp commented Jun 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mtrmac commented Jun 11, 2025

Uh oh!

mtrmac commented Jun 11, 2025

Uh oh!

arsenalzp commented Jun 11, 2025

Uh oh!

mtrmac commented Jun 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Luap99 commented Jun 11, 2025

Uh oh!

justin-octo commented Jun 11, 2025

Uh oh!

justin-octo commented Jun 11, 2025

Uh oh!

mtrmac commented Jun 12, 2025

Uh oh!

kolyshkin left a comment

Choose a reason for hiding this comment

Uh oh!

arsenalzp commented Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

arsenalzp commented Jun 11, 2025 •

edited

Loading

mtrmac commented Jun 11, 2025 •

edited

Loading

arsenalzp commented Jun 13, 2025 •

edited

Loading