"There’s no success quite like failure"

From Accept Defeat: The Neuroscience of Screwing Up:

"This is why other people are so helpful: They shock us out of our cognitive box. “I saw this happen all the time,” Dunbar says. “A scientist would be trying to describe their approach, and they’d be getting a little defensive, and then they’d get this quizzical look on their face. It was like they’d finally understood what was important.”

What turned out to be so important, of course, was the unexpected result, the experimental error that felt like a failure. The answer had been there all along — it was just obscured by the imperfect theory, rendered invisible by our small-minded brain. It’s not until we talk to a colleague or translate our idea into an analogy that we glimpse the meaning in our mistake. Bob Dylan, in other words, was right: There’s no success quite like failure."

Grail Projects in Hudson, Pt 2.

I just recently concluded a first sprints worth of work using Grails for the first time. We delivered.

While cutting the release, I found one additional gotcha in our CI environment. The grails application.properties file holds several key pieces of information including the version number, grails plugin versions and the last build date. This means the file must be checked into source control, but is also modified locally every build by CI (Hudson, nudge, nudge, wink wink). This caused our build to fail while bumping our project version.

1. CI will fail a grails+maven project if you change the version number of the project in the application.properties file.
   • Workaround: 1) Have your CI project perform a clean checkout instead of an update for you build. 2) At the end of your build, add a custom hook to delete the locally modified application.properties file.
   • Fix: I think have the build timestamp in this file may be a mistake as Grails grows more mature. As an improvement, it should be removed.
     

Grail Projects in Hudson

Here is a quick reference for adding a Grails project to Hudson. I'm assuming the webtest plugin is installed becuase there is no reason not to use it. It rocks. Also note that for integration into my existing maven build, I'm using the built-in Grails v1.1.1 maven integration. The project structure was created via the maven archetype:

mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-4:generate \
-DarchetypeGroupId=org.grails \
-DarchetypeArtifactId=grails-maven-archetype \
-DarchetypeVersion=1.1 \
-DgroupId=com.black -DartifactId=grails-project

With that, here is what works so far:

General sequence (these are also the steps for keeping a development team in synch):

1. svn up

2. grails upgrade --non-interactive

3. mvn clean install -DnonInteractive=true

Notes:

• Step 2 above: This upgrades the grails project to include all core grails plugins and also creates some important files under web-app/WEB-INF (applicationContext.xml, ...). We would rather run mvn grails:exec -Dcommand=upgrade -DnonInteractive, however, this fails with an error: Embedded error: java.lang.reflect.InvocationTargetException
/home/black/dev/branches/parent/grails-project/null/src/war not found. Anybody have an idea on this?
• Step 3 above: This step will upgrade all non-core plugins added/modified/removed since the last checkout. Since grails will ask the "are you sure" question, make sure in CI to add the non-interactive switch as above, which will have the effect of cheerfully answering "Y" to all of grails questions.
  

Problems you may run into:

1. As part of a big maven multiproject build, grails may consume enough memory to produce an out of memory error.
   • Fix: Set MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=150m
   
   


2. Adding new grails plugins to the build will freeze the CI build due to the "are you sure" prompt. The same will happen when removing a grails plugin.
   • Fix: Add the non-interactive switch to the build (mvn -DnonInteractive=true or grails --non-interactive)
   
   


3. Webtest launches a window during the test run that needs a display, so CI may need to run the webtests headless.
   • Fix: Add non-interactive switch to the build (mvn -DnonInteractive=true or grails --non-interactive)
   
   


4. Webtest starts the jetty server on port 8080 by default which may clash with other services on your CI box using that port.
   • Fix: Use the switch mvn -Dserver.port=8183. Note: The webtest.properties file property wt.config.port seems to be used if the code under test were already hosted on another running server besides the provided jetty.
   
   


5. A maven multiproject build that includes a grails project with webtests will look for /test/webtest/conf/webtest.properties in the wrong directory. That is, it will not look in ${basedir}, but always in the root project where you invoked maven to start with.
   
   • Workaround: Create a hudson job that only builds the grails war/webtest project. Create a downstream dependency on your main CI hudson job to trigger this one to build.
   
   
   • Fix: ?? Anyone have an answer for this one?
   
   

I hope this helps. For the few items above that have lingering questions, I would be interested in hearing if you have solved these. Let me know.

"Shipping is a feature."

Another good variation on Perfect is the Enemy of Very Good:

"A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it."
-- http://www.joelonsoftware.com/items/2009/09/23.html

Hudson Gadget For Google Desktop v1.0

For all you developers that rely on Hudson for continuous integration build status, I have released version 1.0 of the Hudson Status Gadget for Google Desktop. The code is part of the Hudson project itself, so it is open source.

More information can be found on its home page.

Release note highlights for version 1.0:

• In addition to monitoring the multiple main hudson dashboards, any tabbed view can be also be monitored
• A scrollbar shows for a large number of jobs that would take more space then the gadget allows
• Views can be collapsed to a single line with all jobs statuses of that view aggregating their status to the single view line
• A refresh button has been added for manual status refreshes
• Blinking build statuses are now animated

Enjoy and let me know how it works out for you.