[27.x backport] api: GET /images/json: preserve original manifest order #48712
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
--tree
flag docker/cli#4982 (comment)The
manifests
option, as used for the--tree
option ondocker image ls
currently sorts manifests to put those that are present first. The intent was to present "available" images at the top of each tree, followed by images that were not pulled.However, there's some limitations to this. First of all, the current approach makes the output non-deterministic as the order in which variants are pulled determines the order in which they're presented, i.e., the last pulled variant is returned first (I omitted some variants in the example for brevity);
Here's the result of pulling
linux/riscv64
, then pullinglinux/arm64
;Repeating the steps but in reverse order results in the output to be reversed;
The second limitation is that order sometimes matters; when matching a platform from a manifest-index, implementations may find multiple suitable candidates. In most cases the most suitable candidate can be selected (e.g., prefer
linux/arm/v7
overlinux/arm/v6
), but manifest-indices do allow multiple entries for the same platform, in which case implementations match the first entry found.While these situations will be less common (and usually due to incorect use of tooling such as
docker manifest
), being able to observe the order in which manifests appeared in the index can help debugging or help the user understand why a specific variant was selected.We should therefore not re-order these manifests, and return them in the order in which they appeared. If we decide to present "present" variants before "non-present" variants, we can do this ordering on the client side.
With this patch applied;
Which matches the order of the manifests in the index:
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)