I am currently enhancing the release process of our projects on Jenkins (1.430).
Current release jobs
Today, for one specific project, we have one job dedicated to the Release process. The complete procedure is the following:
mvn versions:set -DnewVersion=2.0
) to get rid of the -SNAPSHOT
.2.1-SNAPSHOT
).The advantage of this method is that I have only Jenkins job, as the build will rely only on a tag.
However, this procedure involves too many human interventiosns (changes of the pom.xml, commits, tags, etc.).
New release jobs
Now, I use the Maven release plugin. I've created a job that asks three information to the user who launches the build:
releaseVersion
of the release plugin);developmentVersion
of the release plugin);tag
of the release plugin).This job works fine, except for one point: the job is based on the trunk or on a branch in SVN. This means that if I have 2 branches (in addition to the trunk), I will need to create 3 release jobs: one per branch.
One idea to keep the best of the two worlds (i.e. using mvn release, but keeping 1 release job) it to add a build parameter that will ask the user for the path of the trunk / branch.
So instead of setting http://my-svn-repo/project/trunk
(or http://my-svn-repo/project/branches/BRANCH_V1
) in the job configuration, I will set http://my-svn-repo/project/$FROM_BRANCH
, and ask the user to input the FROM_BRANCH
parameter.
The problem with this solution is that the user will have to input either trunk
or branches/BRANCH_Vx
, which may lead to errors.
Ideally, I would love to have a build parameter that let me the choice of the branch (including trunk), as the parameter List Subversion tags exist for the choice of tags...
So my question: is there a better way to configure one Jenkins job that can work on all the branches?
Thanks.
Edit: I found the Validating String Jenkins plugin that can be interesting to ensure that the value defined by the user respects some regular expression. That is helpful in my case...
On the job configuration page, enable the release build configuration under the Build Wrapper heading and add your required release version template string, release parameters, pre and post build steps that you need to complete a release.
Save the Job Configuration and Build the Job according to your requirement. Step 1− If multi node selection was enabled, you get the chance to select multiple nodes to run the job on. The job will then be executed on each of the nodes, one after the other or concurrent - depending on the configuration.
Use Authorize Project plugin to assign authentication to your builds. Then Just set Computer/Build permissions for you nodes (Can be done in Role Strategy plugin for example) Use Job Restrictions Plugin to restrict access to node via Node properties.
Just to add some notes to Peter's answer if you are not so familiar with jenkins.
The subversion plugin is installed by default in recent versions(as for Sep 2015).
Then you should configure your project as following:
check following screenshots:
You need version 1.32 of the subversion plugin. The issue JENKINS-10678 was implemented in that version.
Then you only give it your project URL (which needs to contain trunk, branches, and tags) and it will offer you the trunk together with your branches.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With