Using Hudson (Jenkins) to create GIT Tags and Branches Automatically

Recently I had to change our Hudson (Jenkins) setup to tag our “Release” branch every time we made a release.  We also wanted to tag a copy of the release branch every time we wiped it and took a fresh copy from master.  I figured I would share some of the how-to aspects of getting this working.

When you install GIT into your Hudson server there are a couple really handy tools that come installed.  We are going to utilize and explore the GIT Publisher plugin today.

Setting up your Git Repository in Hudson

We are not going to spend time going over all of the settings to setup your GIT Repository here in this post.  However for now there is one part of the GIT Repo setup in Hudson that we do have to cover.  You need to ensure that your GIT Repository is setup with a “Name” Alias.  Look at the following image:

Hudson Source Code Management

This image depicts the standard GIT Repository setup menu.  In order for the GIT Publisher plugin to work properly, you need to ensure that there is a “Name” setup for your GIT Repository.  You will use this “Name” in the GIT Publisher plugin to reference the GIT Repository that you want to publish your Tag and Branches to.  In this example we have setup the alias of “RepoName” that we will use later in this post.

 

Creating a TAG using the Hudson GIT Publisher Plugin

Once your GIT Repo is setup we can then start taking a look at the GIT Publisher plugin.  Scroll down your Hudson config page and check to enable the GIT Publisher plugin.  You should see the following on your screen.

Hudson GIT Publisher

Click “Add Tag” to begin the process of adding a tag.

You will then be presented with a screen that looks similar to the following:

Hudson GIT Publisher Tags

 

Now let’s go over some of the settings here.

“Tag to Push”.  This setting represents the name of the TAG as it will end up on the GIT Repository.   In this example we are using a combination of a text literal “TAG-” and a hudson variable “$BUILD_ID”.   Our build ID’s are the timestamp so in this example the tag name will look something like:  “TAG-2013-03-18_18-31-07” which is basically “TAG-YEAR-MONTH-DAY_HOUR-MINUTE-SECONDS”.

“Create new Tag”.  If checked the plugin will attempt to create a new tag with the name from “Tag to Push”.  IMPORTANT.  If this option is checked and the specified tag name already exists — then the plugin will fail.  If the option is not checked and the specified tag name does not exist — then the plugin will fail.  In other words…

  • If Checked: The tag name cannot yet exist
  • If Not Checked: The tag name has to already exist.

“Target Remote Name”.  This is the reference name of the repository that you setup above at the start of the post.  Notice that we are using the alias “RepoName” that we setup earlier.

That’s It.  The build job will now create a tag of the build after it has completed.

 

Creating a Branch using the Hudson GIT Publisher Plugin

The Branch portion of the GIT Publisher plugin is just as easy to use.  Let’s look at how to use it.  From the Git Publisher screen select the button that says “Add Branch”.  You should see a screen that looks similar to the following:

Hudson Git Publisher Create Branch

Similar to the create TAG inputs we have the following options:

“Branch to Push”.  This is the name of the branch that we want to create.  In this example we are using a combination of a text literal “BRANCH-” and a hudson variable “$BUILD_ID”.   Our build ID’s are the timestamp so in this example the branch name will look something like:  “BRANCH-2013-03-18_18-31-07” which is basically “BRANCH-YEAR-MONTH-DAY_HOUR-MINUTE-SECONDS”.

“Target Remote Name”.  This is the reference name of the repository that you setup above at the start of the post.  Notice that we are using the alias “RepoName” that we setup earlier.

 

When does Execution Happen?

One important thing to keep in mind is that these are POST-BUILD actions.  Meaning that they happen at the end of the build process.  If you need to create a tag or a branch before executing a build then there is an easy workaround for this.

Let’s assume that you maintain a branch called “Release Branch” that gets re-created every development cycle or sprint.  This allows you to silo your code into sprints and control major and minor code releases.  Let’s assume that at the start of each sprint you create a new release branch and want to tag the old release branch.

To accomplish this you should use the following steps:

  1. Create your “Tag” process as a seperate build job using the instructions above.  That is all that the build job does — it just checks out the branch and tags it.  Tt does not build code, does not change the branch, etc.
  2. In your build job that will “create” the release branch (in essence delete the existing branch or update the branch with your code from master) you should specify your tag build job as a build pre-requisite.

You can accomplish Step #2 above by going into Hudson and adding a build step before any other steps.  The image below illustrates this option:

Hudson Trigger Other Jobs First

After you select this option “Trigger/Call builds on other projects” you can then setup the parameters.

Hudson Call Other Builds First

In this case we want to specify the name of the build to run as well as what to do if the build either fails or becomes unstable.  For simplicity, If the build we are calling fails or becomes unstable, we want to simply copy the same status over into our build.

Using this method you can now call your “Tag” build job before your code build runs so that you can tag any code before it gets changed.

 

Conclusion

So that’s about it.  Pushing Tags and Branches via GIT using Hudson (Jenkins) really couldn’t be easier.  The GIT Publisher plugin allows you to easily setup a new TAG or BRANCH after your build completes.  You can also easily setup this plugin to run as it’s own Hudson job so that it can be called as a pre-requisite for other jobs.

Comments

comments

Posted in and tagged , .