Gitversion: Docker naming scheme

[asbjornu]

As discussed in https://github.com/GitTools/GitVersion/pull/1571#discussion_r249751741, it would be beneficial for us if GitTools didn't have 4 different repositories for GitVersion:

• gitversion-fullfx
• gitversion-dotnetcore
• gitversion
• libgit2sharp-mono

I believe having these four options publicly available makes it unnecessary hard to choose which Docker image to use and the naming standard of the tags in each repository is also a bit hard to understand.

I think it would be beneficial to us and our users if we ended up with just one Docker image and associated repository, simply called gitversion and that the tag naming scheme of this repository followed that of NGINX, which would give us the tag format {version}-{platform}-{framework}. For example:

• 4.0.0-centos
• 4.0.1-beta2-debian-fx
• 4.0.0-beta15-windows-dotnetcore
• latest-ubuntu
• latest-windows
• stable-ubuntu
• stable-windows

I have a whole heap of unanswered questions related to this:

• Is this at all possible?
• Can we obsolete repositories so they aren't listed, but still have their contained images be usable for those who are using them?
• Can we clean up the visible tags of a repository without making the images for those tags unavailable?
• Will the proposed naming scheme support all the different variations we want and need?
• Are there anything I haven't thought of?

[arturcic]

• Is this at all possible?

I think we can.

• Can we obsolete repositories so they aren't listed, but still have their contained images be usable for those who are using them?

As far as I know, on Dockerhub there is no option to unlist a repo - it is either delete the repo or make it private, in any case the images will not be available for consumption externally

• Can we clean up the visible tags of a repository without making the images for those tags unavailable?

There is a different option, we can keep the images from gitversion-dotnetcore and gitversion-fullfx by re-publishing to gitversion repository all the tags, using the new scheme - for that we'll need a script to pull them all and re-tag with new tags and then push them to new repo.

[arturcic]

• Will the proposed naming scheme support all the different variations we want and need?
  Currently we support 2 OSes - windows and linux, and 2 variants for both - fullfx and dotnetcore, meaning 4 images.

Now by adding a new distro, we should add distro information in the tag as well. So I suggest we have this extended scheme:

{version}-{os}-{distro}-{framework}-{framework-version} - that's the full tag name.
where
{version} - could be full semver, major.minor.patch or latest
{os} - could be windows or linux
{distro} - could be debian, centos, fedora, ubuntu, or nano, windowsservercore
{framework} - could be fullfx, corefx (full framework for windows or mono for linux, dotnetcore)
{framework-version} - could be 2.1 or 2.2 for dotnet core or 4.7.2 for full framework

For previews will tag the images with something similar to
4.0.1-beta2-linux-debian-fullfx and latest-linux-debian-fullfx

For stable versions will tag with
4.0.1-linux-debian-corefx and linux-debian-corefx

We'll also have default tags like linux pointing to linux-debian-corefx and windows pointing to windows-nano-corefx

The latest tag will point to latest-linux-debian-corefx on linux and latest-windows-nano-corefx on windows

[arturcic]

@asbjornu can you review my comments?

[asbjornu]

Thanks for the clarifications and insight, @arturcic. Yep, all of that makes sense and I agree. I'm just wondering about this:

The latest tag will point to latest-linux-debian-corefx on linux and latest-windows-nano-corefx on windows

Will the docker executable know which OS it runs on and choose the correct "pointer" when using latest or will we need a latest-windows and latest-linux version that people have to explicitly choose?

[arturcic]

The docker cli knows the target OS when you run it, and on windows you can switch from windows to linux and it will know to pull the linux image.

That's how the docker dotnet images are tagged for example dotnet - they have latest for linux amd64, latest for linux arm32, latest for windows amd64 and latest for windows arm32

[arturcic]

I think we should also include the framework version, so that we can support dotnet core 2.1 and 2.2 as well as for the full framework 4.7.2

[asbjornu]

I think we should also include the framework version, so that we can support dotnet core 2.1 and 2.2 as well as for the full framework 4.7.2

Can't we use the same framework notation as the one used in MSBuild's <TargetFramework>? Such as:

• netcoreapp2.1
• netcoreapp2.2
• net472

[arturcic]

I think we can

[asbjornu]

Excellent. Then we end up with the tag format {version}-{os}-{distro}-{targetframework} and the following example tags:

• 4.0.1-beta2-linux-debian-net472
• 4.0.1-beta2-windows-net472
• 4.0.1-linux-debian-netcoreapp2.2
• 4.0.1-windows-nano-netcoreapp2.2
• latest-linux-centos-net451
• latest-windows-net451
• latest
• linux
• windows

The only thing I'm unsure of is the placement of {targetframework}. Would it make more or less sense to put it directly after the version number as {version}-{targetframework}-{os}-{distro}?

• 4.0.1-beta2-net472-linux-debian
• 4.0.1-netcoreapp2.2-windows-nano

[arturcic]

I would prefer to leave it at the end as it's the least important part in my opinion. The OS and maybe distro is the important part, as well as the GitVersion itself

[asbjornu]

Ok, I agree. {version}-{os}-{distro}-{targetframework} it is, then.

[arturcic]

Closed by #1603