## Context Part of https://gitlab.com/groups/gitlab-org/-/epics/11952+. ## Task Using the below screenshot from https://gitlab.com/jdrpereira/multi-arch/container_registry/1245177...  ... and knowing that tag `1.0.0` points to a manifest list/index, when expanding the details of this tag, we should see the digest, platform/architecture, and platform/OS of the manifests referenced by that list/index. In the example above, we'd see that the list/index tagged with `1.0.0` references two manifests, one with digest `sha256:dbd3f975d9c1d9727b3fcc3954c006f933319c1bc278cc304d21b9127bf2cabd` (tagged as `1.0.0-amd64`) and another with digest `sha256:b41fa10fdc1b5f3183d1f310066923a05af8c4e44500e2bb059ef4b956408468` (tagged as `1.0.0-arm64v8`). By looking at the payload of the underlying list/index, we also know that the former targets the `linux/amd64` OS/architecture, and the latter `linux/arm64`. So when expanded, in the tag details of `1.0.0`, we'd see a list with something like this below the `Manifest digest:` row (remember, there is no `Configuration digest:` for lists/indexes - https://gitlab.com/gitlab-org/gitlab/-/issues/408863): ``` References: - sha256:b41fa10fdc1b5f3183d1f310066923a05af8c4e44500e2bb059ef4b956408468 [linux/amd64] - sha256:b41fa10fdc1b5f3183d1f310066923a05af8c4e44500e2bb059ef4b956408468 [linux/arm64] ``` Note that we're not including the tag names `1.0.0-amd64` and `1.0.0-arm64v8` in the information above. Although after https://gitlab.com/groups/gitlab-org/-/epics/10208 the Rails frontend/backend will have a list of tags alongside their manifest digest (based on which we could look up each of the digests above to find out their tag names, and then display them in the info above), we're using paginated requests, so a lookup with just this information would only be possible if both the list/index and all referenced images were on the same page. We'll leave this cross-referencing for a future iteration, as we'll have to build additional discoverability capabilities into the registry API to reverse lookup tags. ## Implementation To accomplish this we'll need to: 1. ~rails ~frontend: **When** expanding the details of tag `X` that points to a list/index, ask Rails for its details. This should ideally happen on a separate page (https://gitlab.com/gitlab-org/gitlab/-/issues/497121+). Instead, and as a possible intermediate step, we may be able to trigger this query when expanding the current accordion icon/pane. 2. ~rails ~backend: When receiving the above request, query a new registry API (https://gitlab.com/gitlab-org/container-registry/-/issues/1393+) to obtain the details for the tag, which will include the target OS/platform. 3. ~rails ~frontend: With the new information in hand, render it in the UI. **Note:** While this requires a second request to obtain the additional details, manifest lists/indexes are the minority, so this is expected to only be required for a small portion of the tags. If this changes in the future, and/or performance becomes a concern, we can work on expanding the tags list API in the registry to account for these extra details (https://gitlab.com/gitlab-org/gitlab/-/issues/369852). However, at this time, that would be far more complex that the proposed solution.