As an example, we will use code snipets from the repository Gradle Semantic Versioning With Jenkins Example.
We will also use this Gradle plugin from Vivin Paliath repository.
1. Gradle Configuration
First, we will see how to configure Gradle to use semantic version
1.1. build.gradle
In the build.gradle file, the only thing to notice is that there is no version variable. It is handled by the semantic versioning plugin.
1.2. semantic-build-versioning.gradle
The semantic-build-versioning.gradle file is required but we could leave it empty. We will configure a startingVersion and tagPrefix.
This way, as we will see, the first tag created by the plugin will be v1.0.0
1.3. settings.gradle
In this file we add the semantic versioning plugin to be used by the Gradle build
2. Jenkins Configuration
Now we will configure a release build using a Jenkinsfile file. And to make things simpler, we will configure a local Git repository.
2.1. Checkout stage
In the Checkout stage we configure a local repository. Also this stage aborts the build if there is no new version since the last release.
2.2. Build stage
In the build stage we issue a command to print the release version:
sh "./gradlew -Prelease -q printVersion"
The -Prelease parameter specifies that this build is a release build. An example of output of this command is seen below:
1.0.20
2.3. Release stage
In the release stage we issue the command that generates the release version and mark this release with a tag.
sh "./gradlew -Prelease tag --console=plain"
And because we configured a tagPrefix property, the resulting tag applied to the repository is, for example
v1.0.20
3. Releasing software
With the configuration files in place and Jenkins project configured to this repository we can start releasing software.
3.1. Semantics
We can start making use of the plugin to increment patch, minor or major parts of the project version through comments we put in the commits.
Let's start our example with this commit:
3994486 (tag: v1.0.0) Initial commit
3.1.1. First, we commit with patch int the commit message:
$ git commit -m "[patch] patch message"
After we run the release build, we should get a git log like this:
a95356b (tag: v1.0.1, origin/master) [patch] patch message
3.1.2. Then we commit with minor in the commit message:
$ git commit -m "[minor] minor message"
After we run the release build, we should get a git log like this:
777faa6 (tag: v1.1.0) [minor] minor message
3.1.3. Then we commit with major in the commit message:
$ git commit -m "[major] major message"
After we run the release build, we should get a git log like this:
887d6de (tag: v2.0.0) [major] major message
4. Conclusion
The Gradle semantic versioning plugin is a great tool that gives the developers the power to decide how the release versions will evolve, which makes perfect sense when we have a Devops culture in place.
I would like to thank you for reading this post and hope it'll be of some help for you.
Regards!
