KhronosGroup / DockerContainers

Docker container specifications which package dependencies for building Khronos documentation and software
Apache License 2.0
7 stars 10 forks source link

Remove `.latest` suffix from tag names #16

Closed MarijnS95 closed 2 years ago

MarijnS95 commented 2 years ago

This suffix is pretty nonstandard, and looks ugly. Typically latest is used as the sole value of a tag given that the "type" of an image is already covered in the "repo" part of the name (i.e. KhronosGroup/$DOCKERFILE:latest). .$VERSION remains as that is what is already actively used.

Over time we can hopefully switch to the KhronosGroup/$DOCKERFILE:latest + KhronosGroup/$DOCKERFILE:$VERSION format across all images.

MarijnS95 commented 2 years ago

@oddhack I take it you prefer this naming scheme then, instead of #17?

MarijnS95 commented 2 years ago

Actually, let's get this in and drop the suffix regardless; #17 is anyway a totally different naming scheme that can be applied on top - which we can discuss separately.

oddhack commented 2 years ago

@oddhack I take it you prefer this naming scheme then, instead of #17?

In that it doesn't require me to create nearly a dozen more repositories and try to find all the Khronos code repositories where we're using the images in CI to rename them, yes.

If we were creating images that were going to get very wide use outside Khronos then complying with common Dockerhub naming practice would be more appealing. But AFAIK the use cases for these images are in our own CI, and for people wanting to build the specs themselves. So from my point of view, I just want to do whatever we need to do to get you to comfortable place building Ash in CI, and not do anything else I don't have to for the other images I use, and this seems like a minimal change to that end.

MarijnS95 commented 2 years ago

In that it doesn't require me to create nearly a dozen more repositories and try to find all the Khronos code repositories where we're using the images in CI to rename them, yes.

In case code repositories refer to GitHub/GitLab, there's no 1:1 relation between those and a Docker repository.


Let's keep it this way then, for consistency. I'm fine with khronosgroup/docker-images:rust, in favour of keeping the scripts simpler! Feel free to get rid of khronosgroup/rust again :), and merge this one in. Also feel free to delete all the "wrong" tags with .latest suffix on DockerHub again, before people start to rely on them.

oddhack commented 2 years ago

In case code repositories refer to GitHub/GitLab, there's no 1:1 relation between those and a Docker repository.

True, but the code repositories will need their CI scripts updated to pull from the new image path. Off the top of my head, I don't actually remember all the repos where I configured CI to use one of these images, as I've been helping out a number of WGs to transition to asciidoctor. If there is some way to automate, say, "search every text file in every github.com/KhronosGroup repository for one of these image names" (and maybe there is, after all I just learned about "git grep" a few months ago), that would help.

oddhack commented 2 years ago

In any event, if @rpavlik is also OK with this then they should feel free to merge it.

MarijnS95 commented 2 years ago

If there is some way to automate, say, "search every text file in every github.com/KhronosGroup repository for one of these image names" (and maybe there is, after all I just learned about "git grep" a few months ago), that would help.

You'd probably need to search on GitHub globally or anywhere else (i.e. GitLab) where repos are hosted.

Perhaps https://github.com/search?l=&q=docker-images+user%3Akhronosgroup&type=code helps, but I've found GH Search to be rather flaky/incomplete from time to time. Perhaps their new https://cs.github.com does it better.


Thanks for merging this, @rpavlik or @oddhack can you remove the noisy .latest tags from dockerhub again? Feel free to remove khronosgroup/rust again, I'm fine using khronosgroup/docker-images:rust as discussed previously (for publishing consistency, too).