JavaScript continuous integration with Hudson and JsTestDriver
JsTestDriver's JUnit compatible XML output makes it dead simple to set up JavaScript continuous integration. This post will help you get started with Hudson.
Installing Hudson
Setting up continuous integration with Hudson is pretty simple - especially if you're on a Debian based Linux. hudson-ci.org has a nice and simple recipe for installing the Hudson .deb:
wget -O /tmp/key http://hudson-ci.org/debian/hudson-ci.org.key
sudo apt-key add /tmp/key
wget -O /tmp/hudson.deb http://hudson-ci.org/latest/debian/hudson.deb
sudo dpkg --install /tmp/hudson.deb
The .deb will not automatically install dependencies, so depending on your system, the installation might fail in the face of missing dependencies. If that's the case, simply copy the name of the missing packages, and run `apt-get install pacakge1 package2`. In my case I was missing the daemon package, so I also had to run
sudo apt-get install daemon
And then the Hudson install finished automatically.
This is really all you need, and Hudson should now be running on http://localhost:8080.
Installing required plugins
In order to run the tests with Hudson we need to install a single plugin. Depending on your version control software of choice, you might also want to get a plugin to support it. I use Git, so I'll show you how to run JsTestDriver jobs from a Git repository.
From the frontpage, click on "Manage Hudson", then "Manage Plugins". Hit the "Available" pane. Tick the checkbox next to "Git Plugin" (if you use Git), and the box next to "xUnit Plugin". All the way in the lower right corner you will find an "Install" button. Click it. When Hudson completes the installation, follow through and click the "Restart when no jobs are running" button.
Configuring a JsTestDriver project with Hudson
When Hudson is back up, click the create new job displayed on the restart page. Give the job a name, such as "My Tested JS Project". Choose to "Build a free-style software project" and then hit "OK".
Optional: Configure the Git repository
If you use Git, choose the Git option under "Source Code Management". New fields will appear. The easiest way to test is to just create a temporary local repository:
➜ ~ mkdir -p /tmp/git/myproject.git
➜ ~ git init --bare /tmp/git/myproject.git
Tell Hudson the location of the Git repository by entering "file:///tmp/git/myproject.git" into the "URL of repository" field. The rest are optional, if you don't know what to do with them, just leave them as is.
Also, importantly, Hudson will fail unless you configure Git for the hudson user. This is simple to do:
➜ ~ sudo su hudson
➜ ~ git config --global user.name "Hudson"
➜ ~ git config --global user.email "hudson@localhost"
Build triggers
Next we need to set up a build trigger. You will likely have your own opinion on how to do this, but for the purpose of this guide, we will set Hudson to poll the SCM. When you tick the box next to "Poll the SCM", Hudson prompts for a schedule. It expects a cron-like pattern. For instance, to poll once every hour on the hour, enter 0 * * * *.
Build step
We only need one build step in this project, namely the JsTestDriver task. Hit "Add build step" and select "Execute shell". Then enter the following command:
java -jar test/JsTestDriver-1.2.2.jar \
--config jsTestDriver.conf \
--server http://localhost:4223
--tests all --testOutput . --reset
Note that this assumes that you will make sure the server runs separately, and that it has browsers attached to it. I've found this to work the best. It also assumes that you bundle JsTestDriver-1.2.2.jar inside the test directory in your project. If this is not the case, adjust accordingly. Same goes for the path to the configuration file.
Post-build Actions
Under "Post-build Actions", select "Publish JUnit test result report", and enter TEST-*.xml as the pattern.
Finally, you can set up Email notification such that team members get an email when the build fails if you prefer. To do so, select "E-mail Notification" and list the desired email addresses separated by a space.
Finally, hit "Save" and your project should be created.
Start the JsTestDriver server
From the same machine, start JsTestDriver on port 4223:
java -jar test/JsTestDriver-1.2.2.jar --port 4223
Capture a few browsers to http://localhost:4223
If you're using Git as I am, push to the local repository:
git remote add local file:///tmp/git/myproject.git
git push local master
Build it
The final step is to try a build. You can either grab a coffee and wait for Hudson to build on the schedule you configured, or you can issue a build manually. In the left column on your project page, there's a link called "Build now". Click it. Now. Hudson will start processing your build, and hopefully if all goes well, it will stop with a blue ball indicating success.
If you're more comfortable with red/green as fail/success indicators, there's a plugin called "Green balls" which you can install from the plugin manager.
When you're all done, it should look something like this:
Comments
Morgan Roderick
(http://roderick.dk)
16. October, 12:34
My team has been using Hudson to run our JsTestDriver tests for quite awhile now, and it's certainly saving us a lot of annoyances, as we get immediate feedback whenever something breaks.
Before we run our JsTestDriver tests, we also use Hudson to run JSLint on our files (excluding tests and libraries).
The only real annoyance with running tests with Hudson, is that it won't run them for EVERY build, but will just fetch the latest revision. This means that it can sometime be hard to figure out which revision broke the build, and which revision fixed it.
Considering how many organisations use Hudson, I find it quite embarrasing that it doesn't support building of every revision out of the box, and that you have to jump through a lot of hoops to get it to do this.
Christian
17. October, 23:17
I can also imagine that, if you use Git, Hudson will only build pushes, and not specific commits. But that would only be a problem if users push too rarely.
Marius
(http://www.zmalltalker.com/)
18. October, 12:46
Regarding the inability to track which commit caused a test failure: if you use Git, git bisect should be very helpful. Git bisect lets you specify a last known "good" commit, then run a specified command for each commit after that until the bad commit is reached (based on the exit code from the command you run).
Sebastiano Armeli
(http://blog.sebarmeli.com)
2. December, 00:44
Thanks for sharing
Comments are closed