Tag Archives: Development support

posts related to development support technologies/issues, e.g. Continuous integration systems, source control management

Jenkins – Tying SVN and Maven with some Groovy script and SVN Hooks – autodiscovering Maven modules on the SCM and automaticly creating Jenkins Jobs

Posted on by
Reply

Jenkins CI

(I took this post out from the ‘shelf’, it was lying here as a the draft for more than two years, anyway, in case it might still be useful, I publish it today :))

Introduction

So, due to the recent build structure change of the main project I work with (Bennu), we ended up with having to deal with ~61 Maven modules, and trying to minimize the changes to the workflow process of the developer. That meant that we wanted to trigger a deploy on Maven of the module’s JAR/WAR, when its code changed, with a simple SCM commit.

Architecture

So, we are still using SVN  for the SCM. (I’m lobbying for Git, and git-flow, which actually is great to tackle some issues we have with the maintenance tasks, and I have been actually profiting from the use of git-svn for quite some time now on my current workspace [yeah, we ended up using it :)])

We have two SCM repositories, a public and a private;

We used an old version of Hudson as a continuous integration (CI) tool (updated to latest version of Jenkins), to make sure the committed code was minimally ok;

We use Sonatype’s Nexus as a Maven repository [although we could have used jenkins itself, I later discovered];

The SCMs, Maven rep, and CI tool are all on the same server (although Jenkins offloads all the work to a more capable server);

We now have ~61 Maven modules to manage all of a sudden (we changed from the old, ant and black voodoo based, module system, to the popular and very handy maven);

Solution

So, we figured that the best would be to have Jenkins deploy to the Maven repository all of the commits that were made, being the committer responsible to update the module’s pom, and in case something went wrong with the compilation of that module, or with any of its dependencies, an email would have been sent warning everybody.

The challenge was to make this automatic i.e.: Having Jenkins sensing the Maven modules amongst other un-mavenized source code, and recognize changes to them on each commit, so that Jenkins is actually able to deploy to the Maven repository the existing modules, and also new ones.

For that job, the solution I came up with was a somehow elaborate SVN hook, that relies on  a couple of conventions, and that creates a new Jenkins job, in case a job doesn’t yet exist for that Maven module, and triggers a build of it upon changes in the SCM of that project’s code.

So, without delay, to the SVN Hook in question:

If you have any comments/feedback, let me know

Jenkins – allowing the ‘build trigger remotely’ functionality with the CAS plugin

Posted on by
Reply

Jenkins CI

Summary

So, right down to it, I gave the feature of allowing ‘build triggers remotely’ to the Jenkins(/Hudson) CAS plugin, thus allowing HTTP GET requests to bypass CAS authentication on ‘build triggers remotely’ links (i.e. http://JENKINS_URL/build?token=SMTHNG). It was one of my ways to give something back to this awesome tool. You can see the code here,  whose pull request has been made , alongside with its issue. Not so interesting reasons of why I did it, are detailed below, comments of code/reasons/whatever are welcome :)

Context

At work, we are starting to use hudson/jenkins to build and deploy each module of the new Bennu structure (~61 modules, all of them a Maven project and deployable on their own, a big change from what we had).

We already used a pre-forked version of Hudson, and seen that I had to make some changes to Hudson, I decided to upgrade. So, the question was Jenkins or Hudson? I Chose Jenkins, why?! no real good reason, I wanted to upgrade, I tried to google the choice, and found something in favor of Jenkins, plus the fact that the main community moved to Jenkins and the fact that I know that corporations can be tough on O.S., and I’m all in favor of open source, I chose Jenkins :).

Anywho, before I realized that Jenkins has SSH access (!!) I decided to tackle an old problem that I had solved before with the use of Apache, that was authentication on Jenkins through CAS. We had chosen Apache before to handle CAS authentication, instead of the Hudson CAS plugin, because it was the simplest way to allow CAS authentication while making sure that the ‘build trigger remotely’ urls (something like http://JENKINS_URL/build?token=SMTHNG) were accessible without CAS authentication for some hosts, so that my SVN hooks could have trigger the build when something had changed. We weren’t actually very happy with the Apache solution, as it sometimes the connection fails with a segfault on the Apache side (?! yeah, really!)!! not sure why, not planning on pulling out the GDB, after trying to search a bit for that bug, I just resigned to use it as it was, after all, we didn’t used the web interface all that much. Something that is bound to change with the new infrastructure used for Bennu.