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

Support docker version with build number #78

Open
david-nano opened this issue Dec 25, 2023 · 4 comments
Open

Support docker version with build number #78

david-nano opened this issue Dec 25, 2023 · 4 comments

Comments

@david-nano
Copy link

Docker versions can't use + in tag, hence build bump isn't available if you want to use semver in this case.
Can we have any customization to make different build syntax? like - instead + ?

@ranger6
Copy link
Collaborator

ranger6 commented Dec 25, 2023

Hello,
I am not sure I understand the issue or the idea that might address it. Please provide more details and some examples of what breaks (e.g. specific command line examples) and what would fix it.
I'm not sure what you mean by "Docker versions" .. do you mean tags that you can assign to images? (you mention a problem with plus signs not available in a tag)

There are no plus signs used in the semver tool command line. There are, of course, plus signs used in some version strings: those with "build" parts. And there are hyphens sometimes. These are parts of the Semantic Version numbering standard. I doubt that we'd want to deviate from the standard. And, replacing a plus with a hyphen is sure to cause problems.

But, maybe I don't understand. Again, please clarify.

@david-nano
Copy link
Author

When you tag a docker image, the tag cannot include +. An example might be more clear here:

xdavidt@davidlinux:~$ docker tag nginx:latest nginx:1.2.3+build123
Error parsing reference: "nginx:1.2.3+buidl123" is not a valid repository/tag: invalid reference format
xdavidt@davidlinux:~$ docker tag nginx:latest nginx:1.2.3-build123
xdavidt@davidlinux:~$ 

so if I want to use semver bump build for docker tag, it won't be possible, because by default bump build adding +, example:

xdavidt@davidlinux:~$ semver bump build 1 1.0.0
1.0.0+1

@ranger6
Copy link
Collaborator

ranger6 commented Dec 27, 2023

Thanks for the details. Your problem: Docker does not accept the plus sign in tags.

A quick search around the web turns up this problem that you and others have: it is not possible (in cases where a "build" part is present) to use semantic version strings as tags. There are outstanding requests and submitted issues to Docker asking for a change. I have not looked into Docker responses, how long these requests have been around, etc. See this short discussion and workaround.

One thing to notice is that some people argue that adding build numbers to tags is a bad idea. The workaround is to use the pre-release part to include build information. You could do this with the semver tool. I think this is a bad idea (covered in the above mentioned discussion).

I do not think it is a good idea to change the semver tool so that it produces non-compliant semver strings! At present, semver never produces invalid strings and we should keep it this way.

It seems what you want is a tool that produces Docker tags from input arguments: e.g. takes a semantic version string, a build number, maybe a git commit hash, ... and generates a Docker tag. Or better, a list of tags! It is common to tag the same image with multiple tags: major, major.minor, major.minor.patch, "latest". Start a project!

@ranger6
Copy link
Collaborator

ranger6 commented Dec 27, 2023

You might want to look at an alternative to tags for build metadata.
See:

  1. https://stackoverflow.com/questions/31647843/labelling-images-in-docker
  2. https://nickjanetakis.com/blog/docker-tip-25-adding-metadata-to-your-docker-images-with-labels

Pointing users to specific builds is fraught with problems. Sometimes, however, it is useful to trace back to the specific build: usually faulty dependency management or broken distribution automation. Putting the info in the image is important because the problem may be broken tagging automation (or human error if you're not automated).

If you are not publishing/releasing images, but instead just building snapshots, then using the pre-release workaround might make sense. E.g. 2.1.4-beta4-SNAPSHOT123478

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

No branches or pull requests

2 participants