Automatically specify version in gradle project
background
When developing a Java project, I used to rewrite the version of build.gradle with each release. It's like this.
version = '1.2.0'
With this operation, there were problems in the following points.
--Need to change build.gradle with each release. In some cases, it can cause conflicts. --It is necessary to upgrade the version of build.gradle again after release and add -SNAPSHOT (Example: After releasing 1.2.0, change to 1.3.0-SNAPSHOT). If you forget this and publish, the released version will be overwritten. --During development on a new branch, if you want to release it provisionally for integration testing, you need to specify a unique version in build.gradle and publish it. --I have released it with a local commit omission.
At first, I wanted to write a simple script using the grgit plugin that can use git commands in build.gradle, but the amount of code seems to swell. So, when I was thinking about writing my own plugin, I found something called nebula-release plugin. It seemed to be very feature rich, so I decided to take advantage of it to solve this problem.
build.gradle settings
A description of the nebula-release plugin can be found in the nebula-release-plugin repository. To apply the plugin, add the following settings to build.gradle. There are various other settings, but this is the only one.
plugins {
id 'nebula.release' version '15.3.1'
}
Try to build
During development
First, run ./gradlew build to build. Then, the following files were generated.
$ ls build/libs/
nebula-test-0.1.0-dev.3+618c605.jar
This naming is described in Tasks Provided, with <major>. <Minor>. <Patch> -dev. # + <Hash> after the project name. Conflicts are unlikely because # is the number of commits since the last release and hash is part of the hash value of the commits. Also, if there is an uncommitted file, uncommitted is automatically added like nebula-test-0.1.0-dev.3.uncommitted + 618c605.jar, so it can not be released in this state It has become.
If you want to deploy to the development environment instead of the production environment, and you want to build with the SNAPSHOT version instead of the unique version above, run ./gradlew build snapshot.
$ ls build/libs/
nebula-test-0.1.0-SNAPSHOT.jar
At the time of release
At release time, add the final parameter. This will generate a filename with only "project name + version" and tag it with the current version.
$ ./gradlew final
Inferred project: nebula-test, version: 0.1.0
> Task :release
Tagging repository as v0.1.0
Pushing changes in [v0.1.0] to origin
BUILD SUCCESSFUL in 6s
7 actionable tasks: 4 executed, 3 up-to-date
$
$ ls build/libs/
nebula-test-0.1.0.jar
Then run ./gradlew build again and it will be generated in the next minor version.
$ ls build/libs/
nebula-test-0.2.0-dev.0+726f7c6.jar
Major version / patch version release
If you release without specifying any parameters, the minor version will be released, but if you want to increase the major version or patch version, specify the parameters as follows.
--Major version: ./gradlew final -Prelease.scope = major
--Example: 0.3.0-> 1.0.0
--Patch version: ./gradlew final -Prelease.scope = patch
--Example: 0.3.0-> 0.3.1
Other notes
Share what you noticed using the nebula plugin.
Also publish at release
Add the following line to build.gradle to add the dependency.
tasks.release.dependsOn tasks.publish
If it consists of multiple subprojects, it looks like this.
tasks.release.dependsOn ":sub1:publish", ":sub2:publish", ...
Excluding the tag name prefix
When releasing with ./gradlew final, usually v is added at the beginning like v1.2.0, but if you do not want to add this, add the following line to build.gradle To do.
project.release.tagStrategy.prefixNameWithV = false
Integration with AWS CodeBuild
The nebula plugin looks for the latest tags in the git history, so you always need all the git history. If you are using AWS CodeBuild, you can get the version correctly by specifying Full in" Git clone depth "in the source settings.
Recommended Posts