Version checker seems to pick the wrong latest version on multi-arch images when using SHA about version-checker HOT 1 OPEN

This is a tricky one. There is a couple things going on here.

First thing I noticed was that we are not handling paging properly in most/all our clients. I will create another issue for that.

Next, version-checker is doing a bad job of being architecture aware, leading to the issue above where it picks the wrong architecture as the latest when they both have the same timestamp. To fix this correctly, we should create a node controller. This will expose a map[string]struct{OS, Arch} which should be passed down into our searcher. The searcher can then be aware of which architecture and OS to be filtering for, when getting the latest. An override option may be appropriate here, but let's leave that for later. We should update the metrics to include the os and arch as labels.

The next thing to fix is the clients which do not expose the arch and OS of image tags available. In these cases, we will likely need to swap out the native API for our first class supported clients, in favour of using the fallback generic docker API, which does support getting this information. We will likely need to do a bit of a dance in terms of permissions, in that we get a valid access token/username/password using the native client first, then passing them on correctly to the generic docker client. We shouldn't expect any config API changes.

Lastly, we need to fix the issue of the "composite hashes". When using an image in Kubernetes which has the tag of "", or "latest", and the selected tag that docker pulls is a multi-architecture image, the reported image SHA as part of the "imageID", will be the "composite hash". This means that, the reported image hash will be the hash of the full json payload (denoted in the HTTP header as DOCKER-IMAGE-DIGEST), rather than the particular image digest. To fix this, we should include a "CompositeHash" field as part of the "ImageTag" struct which includes this value, along with the image SHA. The searcher then need to be aware of whether it should compare against the raw SHA value, or the CompositeHash value. Depending on the client, it may never report a composite hash in these cases, and should be tested. If this is the case, we can save some KB and make the CompositeHash field a *string, making the searcher fall back to SHA when nil.

from version-checker.