Build succeeded.

• containerd-build-arm64 : SUCCESS in 7m 08s (non-voting)

Fly-by comment; wondering; what's the behavior of Only() if arches are in a non-consistent order in the manifest? Does it continue searching for the "best match", or does it pick the "first possible match"?

Fly-by comment; wondering; what's the behavior of Only() if arches are in a non-consistent order in the manifest? Does it continue searching for the "best match", or does it pick the "first possible match"?

If that were the case, we'd (currently) be getting linux/arm/v5 every time we request any linux/arm image (since the lists in official images always list the variants in ascending order). 😅

I believe the implementation detail here is specifically in the MatchComparer interface's Less method (and how that gets used deep inside methods like containerd.NewImageWithPlatform).

(I'd point out that anywhere broken by the new fallbacks was probably already broken in the case of ARM variant matching just like the test I fixed, but it's less common and arguably less disruptive. 😬)

I agree with the sentiment of this PR being a needed thing -- however, I've personally seen use cases for both strict and vector matching. Several platforms have adopted containerd's "platform string" syntax for a --platform flag (like Docker), and I wonder if it would make some sense to standardize a syntax of some kind for vector vs exact at the containerd level instead of having each implementation take a different approach for choosing one or the other?

in official images always list the variants in ascending order

oh! I thought they were in reverse order, ignore my comment 👍

I wonder if it would make some sense to standardize a syntax of some kind for vector vs exact at the containerd level instead of having each implementation take a different approach for choosing one or the other?

+1 on that; I recall having discussed a standardised format (and definition how they should be matched for missing (or optional) components in the past with @dmcgowan, @stevvooe and @tonistiigi

Having the standardized syntax for limiting subarchs might be more preferable, but we might need several months for bikeshedding the new syntax.

For v1.5, we need a quick solution to address the incompatibility introduced in #4528 .
My main motivation of this is for image converter (#4881), but probably BuildKit will need this quick solution as well.

So I suggest merging this PR, and revisit the new syntax in v1.6+.

@tianon @thaJeztah @tonistiigi @dmcgowan WDYT?

So I suggest merging this PR, and revisit the new syntax in v1.6+.

SGTM

Yeah, I agree with this -- no matter how that conversation ends up, we'll need an implementation to power it, which I believe this is. 😄

(I'd also just reiterate that #4528 didn't actually break compatibility - it was already broken - it just highlighted an existing edge case incompatibility by making it much more common 😇 ❤️)

LGTM