Automated Testing and Builds w/ Jenkins + Git: Polling and WebHooks

Jenkins is a pretty cool continuous integration tool that adds a much-needed amount of stability to any project that needs to stand the test of any kind of serious production environment.

And combined with git-flow (see here for an introduction on git-flow) it provides a great way of managing the development process, ensuring code quality and stability, and automating deployments.

Aa killer feature of Jenkins is the ability to run automated tests of all aspects of your code every time there is a change in your git repo (or perhaps more likely, a subset of branches in your repo for which code quality and correctness is top priority), and send out an email alert indicating a warning or failure if the changes aren’t up to snuff.

This post will be slightly bitbucket-centric, however the steps to setting this up properly should be similar regardless of the git backend solution you are running or subscribing to (ie: github).

The “wrong way”

When I first set-up Jenkins with GitPlugin I did a bit of reading about how to trigger Jenkins jobs (aka: automated builds and tests) upon commits to a specific git repo and branch (in this case ‘origin,’ which for me was hosted on bitbucket), and everyone seemed to suggest that one simply adds the following post-receive hook:

https://JENKINS_URL/job/JOBNAME/build?token=TOKEN

Where TOKEN is a special token that can be set inside the Jenkins’ project configuration panel.

While this works for a Jenkins install that is open to the world, it fails as soon as you introduce a measure of security. It’s also not clear how to target specific branches. Reading further for a work-around, I found this post on stack overflow which suggested installing a whole new plugin just for BitBucket, which seemed like overkill, and this post which struck me as a bit complicated on the config end of things and too similar to another approach which failed for my needs (ie: security, targeting of specific branches, etc)(OK, I admit I was a bit lazy to try).

… and the “right way”

Finally I found the a blog post “Polling must die: …” (located here) which struck me as being sufficiently opinionated as probably being correct :P.

The end recommendation is to simply add the following post-receive hook wherever your git ‘origin’ is located (if via bitbucket, go to your repo’s Settings -> WebHooks):

http://yourserver/jenkins/git/notifyCommit?url=<URL of the Git repository>&branches=YOUR_BRANCH1,YOUR_BRANCH2

(with the “branches” argument being optional and dug-up from a separate source.)

Along with:

  • Ticking of the “Poll SCM” box in the Jenkins’ project config panel (with no schedule specified).

And finally, in your Jenkins job, the correct specification of which branch you are targeting, ie:

  • Set the “Branches to build” field in the Git Plugin config section to “*/YOUR_BRANCH” (ie: in such a way as to match the branch(es) specified in the above web-hook).

The rest is handled automagically by the SCM polling and Git plugins.

In conclusion this approach allows one to trigger automatic builds upon commits with auto-filtering against the changed branch, and in such a way that works with Jenkins’ security enabled (ie: no need to grant read / execute access to the world, or something else similarly horrific :P).

In the process of writing this article, I also came across this stackoverflow post, which also advocates this approach.


No fancy tricks or popups, simply an article like the above, which I write a few times a month - just for my subscribers.