19
votes

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:

  1. The developer who is in charge of the release changes manually the version of all the pom.xml files (in fact using mvn versions:set -DnewVersion=2.0) to get rid of the -SNAPSHOT.
  2. Then, he creates a tag in SVN (http://my-svn-repo/project/tags/V_2_0 for example).
  3. Once this tag has been created, he logs on our Jenkins server, and starts a Release build.
  4. This build will ask him which tag he wants to use for the build. The job is configured as a Parameterized build, with the parameter List Subversion tags.
  5. Jenkins will then build the artifacts from this tag, and deploy them on our Nexus instance.
  6. Once this is done, the developer set the pom.xml versions to the new development version (i.e. 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:

  • the version of the release (parameter releaseVersion of the release plugin);
  • the version of development, after the release (parameter developmentVersion of the release plugin);
  • the name of the tag (parameter 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...

2
You can also use some modification of my answer here: stackoverflow.com/a/41632406/2886891Honza Zidek

2 Answers

19
votes

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:

  1. check "This build is parameterized" (this project is parametrized in newest versions)
  2. choose "List subverion tags (and more)"
  3. in the name field, set a varaiable name which can be referenced later in the svn url. I choose svnbranch here.
  4. in the Repository URL field, give it your project URL (which needs to contain trunk, branches, and tags)
  5. fill other field as your needs
  6. in source code management, reference the variable defined before in your repository url.

check following screenshots:

enter image description here

enter image description here

10
votes

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.