Add architecture-specific image digests

[jawnsy]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Chainguard publishes multiarch images, which means that there are multiple digests, depending on which architecture we're pinning. For example, if you pin the current kubectl image on amd64, you have a reference like: cgr.dev/chainguard/kubectl:latest@sha256:37f26ea7ed61395c066e5cc5af74ca059a359ab870c4e693732f1f7713d02b61 but if you do the same on arm64, then you'll have: cgr.dev/chainguard/kubectl:latest@sha256:1a71156d990712079b592583fdd29bf5ef17eed21616c757a47edeb1effc9ad3

Describe the solution you'd like
A clear and concise description of what you want to happen.

Add a column for Architecture or add multiple digests, ideally with some way to copy the full image ref that we can pull

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

• Here's a screenshot from the excellent Registry Explorer tool
  
• However, the Chainguard docs show... something else? It's unclear to me where this digest comes from, though it could just be an old one for amd64:
  

[ltagliaferri]

Thank you for raising this, @erikaheidi is looking into implementing this!

[jonjohnsonjr]

Chainguard publishes multiarch images, which means that there are multiple digests, depending on which architecture we're pinning.

You don't need to pin per-architecture. You can just pin to the digest of the image index. In your screenshot, cgr.dev/chainguard/kubectl:latest@sha256:adfbbaa57b185d9923bfdcb313b59d7a1f36e98b57c764f358f49e25f87008fd would pin to latest and allow you to use that image ref on either amd64 or arm64.

from the excellent Registry Explorer tool

😊

However, the Chainguard docs show... something else? It's unclear to me where this digest comes from, though it could just be an old one for amd64:

The edu.chainguard.dev site docs will lag behind the registry API a bit, so you were likely just seeing the the previous digest. Confirming that...

curl -s -H "$(crane auth token -H cgr.dev/chainguard/kubectl)" "https://cgr.dev/v2/chainguard/kubectl/_chainguard/history/latest" | jq . | grep "sha256:eddc9" -C 10
    {
      "updateTimestamp": "2023-08-16T16:26:19.257Z",
      "digest": "sha256:409a4a370b4c7856d8f8d1b46209263715cd8d3088469e23925f2e8d1f13d9a6"
    },
    {
      "updateTimestamp": "2023-08-17T15:23:03.115Z",
      "digest": "sha256:f5b6ac18dd834c943a71f10c44556ca1f8f5e55b894e892cb91755d528b84e94"
    },
    {
      "updateTimestamp": "2023-08-19T00:20:38.269Z",
      "digest": "sha256:eddc9f25ebe511431065d85000927c1f3429cb601031b217b571691377479a66"
    },
    {
      "updateTimestamp": "2023-08-22T00:21:34.761Z",
      "digest": "sha256:adfbbaa57b185d9923bfdcb313b59d7a1f36e98b57c764f358f49e25f87008fd"
    },
    {
      "updateTimestamp": "2023-08-25T00:20:51.821Z",
      "digest": "sha256:2c8e7c727fe2d6461043ddf7fb7b07174f0af895c903e30e33cb9fbeb0277f39"
    },
    {

The API shows sha256:adfbbaa57b185d9923bfdcb313b59d7a1f36e98b57c764f358f49e25f87008fd but the docs were still showing the previous sha256:eddc9f25ebe511431065d85000927c1f3429cb601031b217b571691377479a66.

[jawnsy]

@jonjohnsonjr I am honored to be receiving a reply from container royalty, kind sir 👑

You don't need to pin per-architecture. You can just pin to the digest of the image index.

TIL! That's pretty cool.

So it sounds like nothing really needs to be done here, then, so I'm good with closing this out and defer to y'all on that. Some other suggestions for your consideration:

• Perhaps a little note in the template indicating that things might be behind due to things getting updated on a different cadence
• Adding a page that explains how to run the crane command above to verify digests or link to the GGCR Explorer tool could also be helpful

The context for this is that we use updatecli to get the current digest and open a pull request to pin it to that version. We were comparing the web site and noticed that the digest was different, which is what led to me opening this issue.

[erikaheidi]

Hi @jawnsy ! Thank you for the suggestions. I'll be considering some new strategies for how we could keep these more in sync, but for now I created a separate issue to update the tags history page to contain information as you suggested, also indicating when the doc page was last updated. This is the issue if you want to track it: #1008

I will be closing this issue then, thank you once again for bringing this to our attention.