Microbadger Versions/Docker Tag

[nightah]

📋 Description

This badge is for MicroBadger.
The information it should show is the version which is effectively the Docker tag.
An example can be found at: https://images.microbadger.com/badges/version/alpine.svg

🔗 Data

There is a public API located at https://api.microbadger.com this is the same API that is currently utilised for the existing MicroBadger size based shields (layers and size). Documentation can be found here.

🎤 Motivation

As far as I can tell there's no Docker tag based shield, given that MicroBadger has already been implemented for the other shields I figured this should be low hanging fruit to provide a shield which can be customised for Docker tags.

[calebcartwright]

Thanks for the suggestion @nightah! This sounds quite reasonable to me, and seems pretty straight forward with all the docs and info you've provided.

We've got a great tutorial if you or anyone else would be interested in implementing this, and of course the existing MicroBadger badges can serve as a good reference

https://github.com/badges/shields/tree/master/services/microbadger

[nightah]

Well I gave it a try @calebcartwright, let's see how this goes!

[PyvesB]

To be honest, I'm not super enthusiastic about this.

Our current MicroBadger badges have been having issues for a long time (see #3988, #3437, #2905, #2532, #2489, #1591, #1400 for a few examples). The Microscaling team in charge of the project have warned that it has become a side project for them (see microscaling/microbadger#38 (comment)) and seem to have even stopped responding to GitHub issues in the last few months.

For a bit of extra history and context, we used to integrate with an older service from the Microscaling team, Image Layers. They progressively abandoned it as well, and ultimately we had to drop the Shields badge (see #2352). I'm worried MicroBadger will follow the same fate.

Given the problems with the current badge and the fact that the MicroBadger project is no longer supported, I really don't think it's a good idea to leverage it for any new badges.

I realise this is a lot to ask @nightah given that you've already submitted a PR, but could we not get necessary data from a different API instead?

[calebcartwright]

To be honest, I'm not super enthusiastic about this.

@PyvesB - I was just noticing some weird behavior with these badges and came across the same linked issues that we have inline in comments. I'd imagine most registries have their own APIs that provide version/tag data, maybe we could start out with Docker hub?

[nightah]

I believe most of the linked issues actually relate to the size badge. Because the metadata has been quite flaky recently.

I’ve been following some of them myself because I also have been affected by this. Having said that, I have noticed an improvement with this over the last 2-3 days.
There has not been an issue that could not be resolved with a metadata refresh. Though it’s hard to say if it will stay like this.

Honestly it doesn’t particularly bother me either way. My main thought and approach was that unless the other MicroBager badges are going to be deprecated it probably makes sense to also have the version one. Given that version and layers don’t appear to suffer from the same issue as the size badge.

I haven’t looked hard to see if there’s an alternative API. There is Dockers RESTful API but that isn’t completely documented, though it might be a good place to start.

[nightah]

Regarding the DockerHub v2 API, we can use the following type of endpoint to get the version and image size: https://hub.docker.com/v2/repositories/library/alpine/tags?page_size=1024.

For the version badge we could map the digest in the json payload of the latest tag with the most explicit SemVer tag.

For the size badge we can just utilise full_size in the json payload of the requested tag.

[calebcartwright]

Thanks for digging into it @nightah

Any chance the tags are already sorted and/or there are additional query params we could use? Would prefer to not have to deal with pagination if possible

[nightah]

Unfortunately the API is not documented very well, the endpoint I have posted isn't and there's many others that also are not for the v2 API.

The count field in the return payload specifies the number of tags so perhaps we could initially call the endpoint and then return the page size in accordance with the number retrieved from said field?

Alternatively we could just return a large page size of >1024 like above, but that could have edge cases that we might not catch.

[darkmattercoder]

I also consider microbadger being an orphaned project. My images are not scanned correctly for months and they are not responding anymore to any issues.

[joonas-fi]

Same here, my new project has reported "unknown" image size for days even though DockerHub tells me the image exists.

[nightah]

With #4562 being merged in this will be a viable alternative to utilise over Microbadger, just waiting on this to be deployed and you'll be able to enjoy the benefits of a direct DockerHub integration.

[joonas-fi]

Oh nice! Thank you for bringing that alternative to my attention. And nice work on doing it! 👍