Version autoincrement in pom.xml via Jenkinsfile
Sooner or later, all Java developers solve small problems in the field of Continuos Integration. Not spared this fate and me. I was puzzled by the problem of automatic increment of versions in pom.xml with each iteration of the project build.
Given: maven project with several modules, master pom.xml and Jenkins server (all like real kids).
It is necessary: ​​for each commit to automatically build a project in any branch, and in the develop branch, the project not only builds, but also increments the build number, which is specified by the third number in the version of the type 1.0.100-SNAPSHOT.
')
To automatically build a Java project in brunch, we use a Jenkins project based on the current Multibranch pipeline.
The essence of this workflow is periodically (for example, once a minute), a task is started in the Multibranch pipeline, which determines changes in the branches and starts the assembly for those brunches in which something is committed. At the same time, like in real boys, the real Jenkinsfile is used to build the brunch. A little literacy: Jenkinsfile is Groovy code that defines the sequence and instructions for building a project. They even came up with the special term “pipeline as code” for this. It seemed that there seemed to be nothing complicated - through the groovy script, increment the version number, commit and run the maven build. But here the main problem is drawn - how to prevent subsequent (endless) assemblies after we have updated pom.xml automatically? Yes, in the Jenkins plugin called 'git' (the one that is designed to detect changes in brunches) there is even a special feature - “Polling ignores commits”, but bad luck - it does not work in the Multibranch-pipeline. On this occasion, many users complained and even brought a special Jira-item . So, let's go ahead, we will reinvent our bicycle!
But fortunately, another feature “Exclude branches” works in the git-plugin. Therefore, we will create a special brunch, where we will commit only build numbers for each build and add the name of this brunch to the exceptions (so that new commits do not trigger new assemblies). In fact, this brunch is only needed to store a single number that indicates the build number. This brunch has no ancestors and is called "orphan". To create it, do the following:
And we will place in it a file with the name current.tag, in which we will write the build number. Well, then Jenkinsfile will do everything for you, the source code of which you will find in the repository on the github .
I will not bore you with the code, in short, the Jenkinsfile algorithm is as follows:
As a result, we get this beauty:
Given: maven project with several modules, master pom.xml and Jenkins server (all like real kids).
It is necessary: ​​for each commit to automatically build a project in any branch, and in the develop branch, the project not only builds, but also increments the build number, which is specified by the third number in the version of the type 1.0.100-SNAPSHOT.
')
To automatically build a Java project in brunch, we use a Jenkins project based on the current Multibranch pipeline.
The essence of this workflow is periodically (for example, once a minute), a task is started in the Multibranch pipeline, which determines changes in the branches and starts the assembly for those brunches in which something is committed. At the same time, like in real boys, the real Jenkinsfile is used to build the brunch. A little literacy: Jenkinsfile is Groovy code that defines the sequence and instructions for building a project. They even came up with the special term “pipeline as code” for this. It seemed that there seemed to be nothing complicated - through the groovy script, increment the version number, commit and run the maven build. But here the main problem is drawn - how to prevent subsequent (endless) assemblies after we have updated pom.xml automatically? Yes, in the Jenkins plugin called 'git' (the one that is designed to detect changes in brunches) there is even a special feature - “Polling ignores commits”, but bad luck - it does not work in the Multibranch-pipeline. On this occasion, many users complained and even brought a special Jira-item . So, let's go ahead, we will reinvent our bicycle!
But fortunately, another feature “Exclude branches” works in the git-plugin. Therefore, we will create a special brunch, where we will commit only build numbers for each build and add the name of this brunch to the exceptions (so that new commits do not trigger new assemblies). In fact, this brunch is only needed to store a single number that indicates the build number. This brunch has no ancestors and is called "orphan". To create it, do the following:
git checkout --orphan develop2 git reset --hard And we will place in it a file with the name current.tag, in which we will write the build number. Well, then Jenkinsfile will do everything for you, the source code of which you will find in the repository on the github .
I will not bore you with the code, in short, the Jenkinsfile algorithm is as follows:
- Cloned the project
- Switched to a lonely brunch
- Read the last build number
- Increased build number
- They got the build number in the variable and wrote it in a file in a lonely brunch
- Switched to main brunch
- Parse the version number from pom.xml
- Generated version number based on version from pom.xml and build number
- Upgraded version in the pom.xml master and all its modules using the corresponding maven plugin
- Collected the project with the help of mvn package
As a result, we get this beauty:
Source: https://habr.com/ru/post/316364/
All Articles