Incorrect arch displayed on badge

[Aetherinox]

I was wondering what the "requirements" are, or what this app looks for to determine the arch of a docker image. I figured it was just the label / tag of the docker image, however, I am trying to pull the semver amd64 badge, and it keeps returning arm64

https://img.shields.io/docker/v/thebinaryninja/tvapp2?sort=semver&arch=amd64

I am utilizing the format version-arch.

I need the semver type, because otherwise it shows -development releases

Or is that shields is looking for an image specifically with just the tag amd64 and nothing else to match with. I assumed that this shields app does some form of "grep" to find the word in the string and filter it out if matched.

Edit: No. Creating just the tag amd64 and applying it to the image does not work either.

[chris48s]

Having had a look over the code, the arch query param is ignored when sort=semver

I think the reason this has never been noticed is because this pattern of having individual tags for version-arch is quite unusual. What most projects to is publish a single tag for each release and push multiple images for different architectures to that tag. So you get something like:

That's one tag called 12.9 available for 8 architectures.

I've proposed a change at #10905 which respects the arch param in that situation, but it may not be merged as it is effectively a breaking change for some projects.

[Aetherinox]

I think the reason this has never been noticed is because this pattern of having individual tags for version-arch is quite unusual. What most projects to is publish a single tag for each release and push multiple images for different architectures to that tag.

The problem is that when I initially learned how to create docker images; I must have looked at over 20 different repos, Pihole, Linkwarden, etc. to see how they all assign tags and release, and what I noticed is that they all wildly differ in their practices and how they tag. Some use semver and then assign the arch as a tag, some use version-arch, some use the date the image was built and everything in-between.

So I never saw a "standard" per say that I could follow, which is why I started using the format I did. It seemed clean.

When I push a release for stable, I have two images, with the tags:

• x.x.x-amd64 Tags: x.x.x-amd64, latest
• x.x.x-arm64 Tags: x.x.x-arm64

For development:

• development-amd64 Tags: x.x.x-amd64, development
• development-arm64 Tags: x.x.x-arm64

But if you have a docker image / link that uses proper tagging that I could use as an example, I can look into adjusting. And will work with shield badges.

What I was trying to accomplish with the badge was having it specifically give the version for the semver labeled / amd64 tagged images. I didn't want developmental-amd64 or developmental-arm64 to show in the badge, only x.x.x-amd64

---

Also, thanks for the PR. I tested it out on my local build, and it works great. Now just to hope it gets pushed publicly as I don't use my test server for public stuff.

---

Edit 2: Ok, I think I know what you mean now. I went digging through repositories, and I found this one:

Which lists both archs for a single tag, instead of my method which puts each arch in its own tag.

[Aetherinox]

So, something good came of this discussion.

I ended up reading the docker documentation, and revising the entire workflow.

I was able to remove an entire job (probably over 1200 lines of code between multiple Github workflows), and combined the arm64 and amd64 build into a single step, and then I added a new action to the workflow which pulls the manifest data from the arm64 and amd64 docker images and merge them into a single tag, which gave me what I assume is the more common practice:

Which ends up working out better anyway. I like how Github shows docker image tags. I dislike how Dockerhub shows them. So the less in the list, the better.

And I was even able to eliminate my Dockerfile.aarch64 file, because I ended up adding a new ARG to the main Dockerfile called ARCH and now I just pass the arch when the image is built. And the same Dockerfile now handles both arch.

Ended up being a very productive lesson.

[chris48s]

I think that is the most common setup. That is similar to what we do with ours

That said, it is not necessarily wrong to do it another way. I think PR #10905 still stands in its own right, even if you've also independently arrived at a solution you're happy with to the initial problem.

[Aetherinox]

The PR will definitely help, as I have another docker image which still uses the old format with each arch being on its own, so this will definitely help with that repo. That one can't as easily be converted because of how it is set up.

Appreciate the time and work.