Allow multiple Tags on the same commit

[marcus-held]

Hi,

currently we build a new release version with every build that Jenkins does. This causes the problem that we might want to do another build that starts with a different configuration. But this second build is built on the same commit. The versioning plugin then refuses to do that because it can not create a tag since the commit is already tagged.

Is it possible to allow this? Since the plugin should be able to resolve which tag is the latest on one commit it should be able to determine a proper version.

[vivin]

What would the second tag look like? Are you just looking to change the prefix on the tag?

[vivin]

Closing due to lack of information.

[master-lincoln]

Hey, we also need this to be able to have different build artifacts from the same working tree (say e.g. a debug build and a production build). A suffix would be enough for us (e.g. 1.10.2-1) Would be happy about re-opening!

[vivin]

@master-lincoln The tag identifies a particular version of the code. If you want to build and release multiple artifacts, couldn't you just add a classifier to the jar task for each of those artifacts? I guess I'm having a hard time understanding the value of having a tag 1.10.2 and 1.10.2-debug pointing to the exact same commit. 1.10.2 applies to the entire codebase as a whole, and it's saying that the particular commit identifies an explicit version of the code. Even if there are multiple artifacts corresponding to that version, all of those artifacts must have been generated from that particular tag. Hence the second tag is superfluous because it is attached to the exact same commit.

You shouldn't rely on just the version number (and tag) to identify these multiple artifacts; let's say you have artifact-1.0.0.jar and artifact-1.0.0-source.jar, all it means is that both were generated from version 1.0.0 of the code. So if you wanted to check them out or rebuild them, you would be checking out the 1.0.0 tag regardless of whether you wanted to build artifact-1.0.0.jar or artifact-1.0.0-source.jar.

I think if you look at how artifacts are stored in maven repositories, for example, it works this way well -- you have a single version number but can have multiple artifacts with different classifiers (e.g., a "source" classifier if you want to package the source as well).

So two possible ways to solve your issue are:

• set up your CI process such that only "release" builds get tagged, and other builds (such as "debug") do not.
• set up your gradle config to build and release multiple artifacts by using classifiers.

[master-lincoln]

Thank you for this elaborate answer. You are right, I lost the big picture. As this versioning plugin is only concerned about versioning the code base, we should either make the configuration part of the code base or append classifiers manually to the version strings n the artifacts when building different configurations.