Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker naming scheme #1572

Closed
asbjornu opened this issue Jan 22, 2019 · 12 comments
Closed

Docker naming scheme #1572

asbjornu opened this issue Jan 22, 2019 · 12 comments
Assignees
Labels
Milestone

Comments

@asbjornu
Copy link
Member

As discussed in #1571 (comment), it would be beneficial for us if GitTools didn't have 4 different repositories for GitVersion:

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?
This was referenced Jan 22, 2019
@arturcic
Copy link
Member

arturcic commented Jan 22, 2019

  • 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
Copy link
Member

arturcic commented Jan 22, 2019

  • 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
Copy link
Member

@asbjornu can you review my comments?

@asbjornu
Copy link
Member Author

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
Copy link
Member

arturcic commented Jan 22, 2019

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

I think we can

@asbjornu
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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

@arturcic arturcic self-assigned this Jan 23, 2019
@arturcic arturcic added this to the 5.0.0 milestone Feb 9, 2019
arturcic added a commit to arturcic/GitVersion that referenced this issue Feb 23, 2019
arturcic added a commit to arturcic/GitVersion that referenced this issue Feb 25, 2019
asbjornu pushed a commit that referenced this issue Feb 26, 2019
@arturcic
Copy link
Member

Closed by #1603

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants