cobertura plugin and maven3 in a Hudson Installation

Now that Hudson 1.392 supports Maven3 I switched my first job to Maven3. One small caveat: you need a new, not released version of the Cobertura Plugin, more information is found in HUDSON-8362.

Triggering Hudson parameterized builds which include a file parameter using curl

My final goal is to run mvn release:prepare on my local machine to have greater control and trigger the actual mvn release:perform on Hudson, which will do the deployment in a controlled environment and archive the build log.

To achieve this, I want to upload the generated release.properties to the Hudson instance. This should be possible using the Parameterized Trigger Plugin. The tricky part is that the proposed solution on the plugin's Wikipage using buildWithParameters seems not to work, I always got HTTP/400 or HTTP/500 responses. After some tries and an analyze of the traffic with Charles I came up with two solutions, one using token authentication, the other one basic authentication. The important part seems to be to include the parameters json and Submit as well. Note that the file parameter is numbered, i.e. it is called file0.

Token authentication

curl -i -Fname=release.properties -Ffile0=@FILE_TO_UPLOAD \
-Fjson='{"parameter": {"name": "release.properties", "file": "file0"}}' \
-FSubmit=Build \
'http://HUDSON/hudson/job/JOBNAME/build?token=TOKEN'

The advantage of this is that no further user interaction is required, however you do not know who triggered the build.

Basic HTTP authentication

curl -i -uUSERNAME -Fname=release.properties -Ffile0=@FILE_TO_UPLOAD \
-Fjson='{"parameter": {"name": "release.properties", "file": "file0"}}' \
-FSubmit=Build  'http://HUDSON/hudson/job/JOBNAME/build'

The advantage of this is you know who triggered the build.

Really using launchctl to restart a Hudson Mac OS X build slave connected via JNLP automatically

In my last posting I wrote commands put into $HOME/.launchd.conf would be launched automatically after a login as stated by the man page for launchtctl. However this is false! After a reboot or relogin the commands will not be picked up! Stating man 5 launchd.conf:

$HOME/.launchd.conf  Your launchd configuration file (currently unsupported).

Pulling my ear: always try and test what you write about, sorry :-(. However using the following .plist file put into
$HOME/Library/LaunchAgents/org.hudson-ci.jnlpslave.plist really starts the slave:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>KeepAlive</key>
        <true/>
        <key>Label</key>
        <string>org.hudson-ci.jnlpslave</string>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/bin/java</string>
                <string>-jar</string>
                <string>/home/hudson/bin/slave.jar</string>
                <string>-jnlpUrl</string>
                <string>http://SERVER/hudson/computer/NODE/slave-agent.jnlp</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
</dict>
</plist>

Of course you have to adapt the path to your slave.jar as well as the URL to your Hudson-master.

Using launchctl to restart a Hudson Mac OS X build slave connected via JNLP automatically

$HOME/launchd.conf does not work, see my working followup on this!

In my company's build infrastructure most of the slaves are located in the same data centre as the master. So we usually just use ssh to launch the slave.jar. As we did not want to buy XServe and our operations team would not like to host such an aberration from the usual (Linux) to build the handful of jobs which are Mac OS X only, we bought a Mac-Mini, which is part of the workstation LAN, where hudson will login automatically as we need the GUI anyway for Selenium tests.

As we have very strict firewall rules, access from the server LAN into the workstation LAN is forbidden. That's why we use JNLP to start the slave. So we've usually restarted the slave manually after the connection broke down.

Enters launchctl. Instead of fiddling around with a plist file I just used launchctl submit to achieve the same. From the commandline enter the following command:

launchctl submit -l hudson-slave -- /usr/bin/java -jar /Users/hudson/slave.jar -jnlpUrl http://SERVER:PORT/hudson/computer/NODE/slave-agent.jnlp

This will start the slave and restart it automatically if the connection ever should break down. You may watch the logging statements uttered by the slave by executing
open /Applications/Utilities/Console.app. To enable this command every time your Mac OS X machine reboots, create a .launchd.conf in the hudson user's HOME like this:

cat > /User/hudson/.launchd.conf << EOF
submit -l hudson-slave -- /usr/bin/java -jar /Users/hudson/slave.jar -jnlpUrl http://SERVER:PORT/hudson/computer/NODE/slave-agent.jnlp
EOF

You must not use the javaws way (the -wait option did not work for me), as the parent process will exit after it launched the jnlp connection and launchd will try to restart it again immediately for some times.

Cross browser CSS and selectors - improving Hudson's viewList

After visiting the JBOSS Hudson instance with Firefox I really liked the way how the tabs were shown in the viewList. However revisiting the same page with Chrome was a disappointment. Neither was the active view emphasized nor were the inactive views flowing like they did with Firefox.

After some trials I detected that the attribute selectors in the CSS were not triggered. Digging into element view showed that Chrome did not render a whitespace between the height attribute, so Firefox rendered tr[style='height: 3px;'] while Chrome was rendering tr[style='height:3px;']. After duplicating the selectors and changing some attributes for Chrome I got at least the active view rendered in the right way, see jboss-style.css.

Triggering Hudson builds with Mercurial hooks - a variation

Ashlux writes about triggering Hudson builds with Mercurial hooks on his blog. The basic hook described is:

[hooks]
changegroup.hudson = curl http://hudson_url/job/project_name/build?delay=0sec

I use this technique as well a lot with two refinements:

1. I use polling instead of build. So the url is http://hudson_url/job/project_name/polling. This will poll your Mercurial repository and only if something really changed, the build will be triggered.
2. Instead of setting up authentication I always use the TOKEN approach described on Remote access API, so the url gets http://hudson_url/job/project_name/polling?token=TOKEN

Using tokens you do not need to submit any authentication information. Bitbucket offers a POST service which you may use instead of the aforementioned hook. Github offers a similar service.

Fun with Javascript for Hudson

Right now, I do not have a lot of experience with Javascript but after having seen some funny stuff done to our internal Bugzilla with a userscript (templates for bugreports patched into the comment field), I decided to give it a try. Sometimes jobs in our internal internal build servers (Hudson) will break over night because of full hard drives e.g. So we created a special view with all failed builds and a Hudson extension to build all jobs in a view.

Now I thought this could be easily accomplished with Javascript as well, so I read a little bit about YUI2, which is included in Hudson already and came out with my first Javascript extension, which I host on Bitbucket.
The source code:

• I just save the script in the userContent folder of Hudson and source it in the description of the view like this:
  <script src="/hudson/userContent/hudson_extensions/he-all.js" type="text/javascript"></script>.
• First, I attach the initialization with the help of the YAHOO.util.Event.onDOMReady to the point in time when the whole page is rendered, on my first tries I only collected the links already rendered up to the point where the script was included.
• If any job build links are found (isBuildHref), I render a Build All link.
• When hitting the link, I just iterate over the links (buildAll) and send an asyncRequest discarding the result by not specifying a callback function at all to trigger the actual builds.

Now I already can think of other useful stuff to do with this :-).