Docker tags on each release.

[stavros-k]

Description

Using docker tags based on released version, can help with a lot of things.

• Debugging.
  On bug reports if someone has a docker problem, you don't know which image is using.
• CI
  A lot of CI's depend on the tags to pull the newer images.
• Breaking Changes.
  If there is a breaking change ever, you can't know in which image is the breaking change if they don't have tags to separate them.

Why it should be implemented

Who it would benefit:
App Catalogs that uses CI to pull new images.
eg. https://github.com/truecharts/apps/

Optional: implementation suggestions

This seem to have been requested before, while the issue says the images should be tagged, they are not.
#402

Optional: screenshots

Add some screenshots, mockups, ... if they help clarify what you want

[draeath]

Chiming in here.

We always use versions in our work, in our FROM fields, etc.

You won't get an update for every PR or minor change in the master branch so it's safe to use the latest image.

• maintainer in Tag docker images with specific speedtest version #402

Even if this is true, it's still very nice to provide version tags, even when they're just an alias to latest at the time they're pushed. They don't consume data (at least, they don't in the docker reference registry and dockerhub, or on-disk with podman) so there's little reason not to do it.

The idea is it allows one to be repeatable and to know at a glance what version something is. We can just put the hash in instead, but then we have to maintain a table of what hashes are for what versions somewhere. Kinda gross, on the implementation-side. I'm not even sure we can map the hash to the version, really, since that hash isn't the commit hash, but the hash of the image.

Right now, you've some process that pushes ghcr.io/librespeed/speedtest (maybe with :master?) - all we would need for this to happen is to do it again right after with ghcr.io/librespeed/speedtest:5.3.1 or whatnot. It should be nearly instant and, again, consume no resources on github's end except the image manifest.

EDIT: ah, org.opencontainers.image.revision is being populated and matches the git commit & release tag, so that's good - though it would be nice if org.opencontainers.image.version was also populated.

[sstidl]

hi! feel free to play with your own fork to achieve this.
a quick search brought me to:
https://docs.github.com/en/actions/publishing-packages/publishing-docker-images

if you make it work i will gladly merge your pull request.

[sstidl]

currently the workflow is here:
.github/workflows/docker-publish.yml

[sstidl]

ok, i try it myself ;-)

[sstidl]

fixed in Release 5.3.3
Now we have the following pattern:

• ghcr.io/librespeed/speedtest:5.3.3
• ghcr.io/librespeed/speedtest:5.3
• ghcr.io/librespeed/speedtest:latest

[draeath]

Thanks!