How would I replace snapshot with the git commit hash?

[schauder]

I'd like to set up my CI server (Jenkins) to create nightly builds, those shouldn't change the main version, but should only replace the SNAPSHOT part with the hashcode of the git commit.

How can I do that with this plugin?

[eshepelyuk]

Currently this features is not implemented but you could try to achieve something similar by playing with versionPatterns property of release convention object.
The property allows you to configure matcher and closure that is updating the version.
By default closure increases latest version number, but you can try to configure to substitute hash of git commit instead.
Although this approach won't let you get rid of SNAPSHOT prefix it probably could fit your needs.

[townsfolk]

Evgeny is correct. This is not really possible in this plugin at this time. He's correct, you might be able to play with the versionPatterns to get what you want, but I suspect that would be pretty difficult.

I'm not sure this is actually a good feature for this plugin though, because it's intended to do releases, not really snapshot/dev builds. The concepts are different in Maven as well. There's the Maven Release plugin and then the deployment plugin. To deploy snapshots you use 'mvn deploy', you don't do the 'mvn release:perform' operation. I think it would be better to have a separate task for what you're asking for. Maybe another gradle plugin that allows you to define a snapshot scheme, much like we do here with the versionPatterns.

[schauder]

I'll give the fiddling with the versionPattern a try. Thanks for the pointer

I do think this kind of stuff belongs in a release plugin. I don't really see a difference between releasing
4.3.2 of a project versus 4.3.2-RC3 or 4.3.2-NIGHTLY-build9347

It just differs in the degree of 'completeness' of the code&qa process. If you use completely different plugins for those, how would you be sure that they are actually the same.

[townsfolk]

I don't really see those things as the same as a SNAPSHOT build, which is what you asked about originally. What you've described just above are what I'd consider singular and different versions. Snapshot builds are masked versions that don't have tags associated with them.

Eg. You specify the version as 1.0-SNAPSHOT, maven uploads 1.0-12345678998765432131, but you specify the dependency version as 1.0-SNAPSHOT. Maven figures out which artifact to actually download. When you do a mvn deploy, no VCS tag is created for that.

I think this is what makes them different. To me, this would be like continuously recreating a tag for version 1.0-SNAPSHOT. It's different each time you do a build, but you're telling people they're the same thing.

This plugin can already support the 3 version schemes you mentioned above. This plugin does pre releases for it's dev versions - and tags are created for those. At work we have a version scheme of major.minor.patch.build, so we have a Jenkins job that creates 1.0.0.1, and 1.0.0.2 builds on a nightly basis. This plugin supports this out of the box as well. To get Git revision from within your CI might not be too hard, although it would be a little redundant because the plugin is going to create a tag for that revision.

That being said, I know Jenkins provides System variables for things like this, so you might be able to do a version pattern similar to this:
/(\d+)([^\d]*$)/: { Matcher m ->
m.group() + "-" + System.env["GIT_COMMIT"]
}

But, as I mentioned you're likely going to have a tag that looks like "1.0-GIT_COMMIT" where GIT_COMMIT is the same sha as the tag itself.

NOTE: that this won't work as a SNAPSHOT dependency, your other projects would have to specify the exact sha to get maven or gradle to download it as a dependency.

[schauder]

Sorry, for not being clear about my intend. I'll try the version pattern.

This is for a distribution (a complete java app as zip file) so I don't care if this is considered a Snapshot build or not by other tools.

[townsfolk]

I'll create a ticket to add the Project object to the versionPatterns, that should make it a little easier to do these things.. That way you'll have access to the full version value as well the conventions and properties.