This past week I was charged with creating a custom Continuum notifier which would push a build’s Selenium TestNG test results to a second system for reporting. Changing project priorities, distractions, poor documentation and some weird issues made this simple task take much longer than it should have. Hopefully, this series of posts will help make the process just a little bit smoother for the next person.
Visibility into the quality of a software project is crucial to delivering a top notch product. One direct way to achieve this is monitoring the team’s UAT results over time. I have been slowly pushing the client’s development teams to fully automate their user acceptance testing along side the rest of their build process. Enter Continuum and Maven, the client’s choices for continuous integration and “one button” builds. Out of the box, Continuum had pretty much everything we needed from a testing/reporting standpoint, except that the development teams were spread out across several Continuum installations and management wanted a single place to see ALL teams’ test results. Luckily, I found that Continuum has a plugin architecture for its notifiers – the plugins which decide what to do with the builds’ results. Out of the box, Continuum comes with the ability to email and/or IM your build results in several ways. What I needed was a notifier that would send the testng-results.xml file generated by Maven’s surefire testing plugin via a multi-part HTTP POST request to our reporting app. Sounded simple enough.
Use the Source Luke
A few quick Google searches taught me a couple things: 1) a number of people have wanted to to do exactly what I needed, and 2) there didn’t seem to be any good end-to-end documentation on how to do it. First step, download the source and get it to compile. Next, according to the directions on the main site and the user wiki, was a simple mvn install.
First Build – Fail
Unfortunately, the continuum-release module’s tests fail. I am still looking into why the release module tries to do a SVN commit during a install of the main project and not a deploy, but for the time being, it fails. In order to get past the release module’s issues (the other modules install just fine and pass their tests) I sinned and added a -Dmaven.test.skip=true to the build and continuum-release installed like a champ.
Second Build – I forgot
Boom! Not so fast. OutOfMemoryError from maven while building the web module. Setting MAVEN_OPTS to increase the max heap memory Maven has fixed the problem.
Third Build – Fell off the log
Boom! Again. java.lang.NoClassDefFoundError on Commons Logging coming from the JSPC plugin (precompiling JSPS). It turns out that plugins live in the same classloader as Maven itself and the JSPC plugin requires commons logging. It also turns out that in the latest version of Maven (2.2.0) the internal dependencies changed and the version JSPC is no longer included in Maven’s “uber” .jar. Fix? Dropped 1.1.1 commons logging three .jars into Maven’s lib folder. Fixed.
Fourth Build – Houston, We Have Compilation
Finally, everything compiled and installed without problems. Next up, writing a dummy notifier and getting Continuum to use it.