Archive for the 'CruiseControl.NET' Category

Published by breki on 12 Nov 2009

Changing The Build Server

Recently I’ve upgraded my home development machine to Windows 7. It is useful to do these cleanings from time to time, since it forces you to take a step back from your current configuration and think whether something new might be better.

So yesterday while I was preparing a new release of GroundTruth, I was missing my CruiseControl.NET server and started to reinstall it. After hitting a few snags I got bored with the whole idea: I constantly keep resolving the same issues with CC.NET installations (since I use it both at home and at work). Remembering I once played with Hudson and liked it, I decided to give it a serious try.

Setting Up Hudson

The installation was really easy – just download the .war file and run it using java. I did have to move the home directory from the default user’s profile directory to my data disk in order to make the whole installation more portable.

This is what I like about Hudson: no hassle with XML configuration files, you can configure it with a user-friendly Web GUI. Also, you don’t need IIS – the Hudson has its own integrated web server. And it even provides a button for installing Hudson as a Windows service!

The only real drawback with Hudson is that it’s a Java application and if you want to extend it with your own plug-ins, you need to write Java code. Which is fine, but not as accessible for .NET developers. But lately I’ve started using the build server just for building, labeling and packaging and I don’t really need any special plug-ins for that. Anyway, Hudson already has a lot of plug-ins, some of them even for .NET, so I don’t think I will need to write my own any time soon.

Good Bye Cruising

I’ve had quarrels with CC.NET before. Now I think of CC.NET as a nice introduction into CI world, but after a while you need something else. My view is that the .NET world needs a new open source CI project, which would build upon experience of CC.NET, both positive and negative. This is what I would like to see:

  • No hassle: just copy a single executable and run it. No IIS setup, no nothing. Web server comes with the package. Windows service installation with a single mouse click.
  • Portability: server configuration has to be separated from the server executables. If a new version of the build server arrives, the upgrade be as simple as overwriting a single executable file. No messing around with Web.configs, dashboard.configs etc.
  • Web-based installation & upgrade: I like how WordPress is doing things: you can upgrade your WordPress installation using the Web dashboard. It would also be nice to be able to install plug-ins just by pointing to its home URL.
  • Simple GUI: simple as in “Google search simple”. 95% of the time you only need a build radiator and nothing else. Everything else should be accessible, but not on the first page. And think simple permalinks. BTW: in my view, even Hudson’s GUI could be improved in this aspect.
  • Interactive GUI: I want to see a live build log, without manual refreshing. More Ajax please.

Published by breki on 16 Jun 2009

Gallio: Starting And Stopping Selenium Server Automatically During Testing Using AssemblyFixture

UPDATE (June 17th): I’ve updated the code, see the reasons for it at the end of the post.

In previous projects I worked on we made sure the Selenium Java server was running by manually starting it on our machines (both developers’ and build ones). This was cumbersome: restarting the build server meant we had to log on to the server after the reboot and run the Selenium server again. Of course, a lot of times we forgot to do this, which caused the build to fail.

This got me into thinking: is there a way in Gallio to specify some initialization (and cleanup) actions on the test assembly level? And of course, the answer is yes: using the AssemblyFixture attribute. This is what I like about Gallio/MbUnit: most of the time the feature requests I come up with are actually already implemented.

So anyway, you can specify this attribute on a class and then add FixtureSetUp and FixtureTearDown attributes on its methods. These will be executed on the test assembly-level: setup methods will be executed before any test fixtures have been run and teardown methods will be executed before the test assembly has been unloaded by the test runner.

I then used this nice feature to start the Selenium server and then dispose of it after tests:

public class SeleniumTestingSetup : IDisposable
    public void Setup()
        seleniumServerProcess = new Process();
        seleniumServerProcess.StartInfo.FileName = "java";
        seleniumServerProcess.StartInfo.Arguments =
            "-jar ../../../lib/Selenium/selenium-server/selenium-server.jar -port 6371";

    /// <summary>
    /// Performs application-defined tasks associated with freeing, releasing, or
    /// resetting unmanaged resources.
    /// </summary>
    public void Dispose()

    /// <summary>
    /// Disposes the object.
    /// </summary>
    /// <param name="disposing">If <code>false</code>, cleans up native resources. 
    /// If <code>true</code> cleans up both managed and native resources</param>
    protected virtual void Dispose(bool disposing)
        if (false == disposed)
            if (disposing)

            disposed = true;

    private void DisposeOfSeleniumServer()
        if (seleniumServerProcess != null)
                bool result = seleniumServerProcess.WaitForExit(10000);
                seleniumServerProcess = null;

    private bool disposed;
    private Process seleniumServerProcess;

Note that the class is disposable – this ensures the Selenium server is stopped even if you run tests in the debugger and then force the debugger to stop before finishing the work. The Dispose method calls DisposeOfSeleniumServer, which does the actual work of killing the process and disposing of the evidence.

NOTE: This is a second version of the code. I needed to update the old one because I noticed that when running the tests in CruiseControl.NET, the Selenium server java process was not stopped properly. The only way I could stop it is by killing it, which in general isn’t a good practice. The unfortunate side effect of this “killing” is that the CruiseContol.NET service cannot be stopped normally – it also has to be killed when you need to restart it. I’ll try to solve this problem in the future.

Published by breki on 02 Feb 2009

CCNet Filtered Source Control: Ready To Shoot My CI Server

happiness is a warm gun
Creative Commons License photo credit: badjonni

UPDATE (April 1st 2009): no, it’s not an April fool’s joke… The fun continues with the new version of CCNet… read the update below

After about two hours of exercises in futility I finally managed to persuade CruiseControl.NET to start the build when a particular file on the disk changes. I was just about ready to give up and start implementing my own CI software before the following configuration managed to do what I wanted:

<sourcecontrol type="filtered">
    <sourceControlProvider type="filesystem">

Notice the <pathFilter> tag? I have no idea why only this particular filter value works. The file path I wanted to cover is C:\Temp\CopyAndRun.bat. I tried several other (and more logical) filter values, like:

  • CopyAndRun.bat
  • /CopyAndRun.bat
  • \CopyAndRun.bat
  • C:\Temp\CopyAndRun.bat

… and some others, but to no avail, CCNet reported that none of the modified files matched the specified filter. Needless to say I couldn’t find any relevant documentation and samples for this situation.

I’m more and more of the opinion that CCNet, although powerful and flexible, is pretty horrible for configuring and maintaining. Maybe it’s really time for me to start working on my own solution. Well, to be honest, I’ve already made first steps

UPDATE (April 1st 2009): it turns out the new v1.4.3 version decided to do it differently… and breaks the existing behavior, again in an untraceable way. The configuration block I posted above doesn’t work anymore, the new configuration now looks like this:

<sourcecontrol type="filtered">
    <sourceControlProvider type="filesystem">


  • repositoryRoot now must not have a trailing backslash
  • pattern now works without the ** wildcard.

Again, it is very hard to determine the right configuration. The only help (if it is help at all) is the CCNet service log file, but it doesn’t really tell you why a particular file does not match the filter critieria. Urghhhhh…

Published by breki on 14 Jan 2009

Brainstorming: Distributed Continuous Integration System

Beauty and the Beast
Creative Commons License photo credit: eyesore9


This is the second part of my brainstorming "session" about automating software deployment and execution on a remote computer from yesterday. I did some investigation and found a very useful resource (part of the Paul Duvall’s excellent "Automation for the people" series) about patterns for automatic deployment (also see the newest article here). Also check out SmartFrog’s Patterns Of Deployment, which covers deployment topics extensively.

Paul’s approach is to use SCP for secure copying (distributing) of files and SSH for remotely invoking processes. The advantages I see in this approach are that it uses standard protocols and is very flexible, including support for public key infrastructure (PKI). The only thing is that I don’t know which tools to use for Windows for SCP and SSH – I’m looking for free software which would be easy to set up both for clients and for servers. And by "easy set up" I don’t mean MSI installations – I would like a simple copy and run type of installation.

A commenter Jean-Philippe Daigle also suggested among other things using rsync for publishing new build packages to other servers. There is also an rsync alternative for Windows called Unison. Again, I’m not sure how much work is needed to set these things up before using them for CI purposes. And also I see a problem of using a bunch of tools each of which solves only a part of the problem – from my experience this results in a CI setup which is fairly brittle.

Feedback Problem

I thought a little about how the continuous integration (CI) process would look like if I implemented an Agent service described in the previous article. The main problem I detected was the lack of good feedback from such an Agent – if it were to run our long running integration tests we wouldn’t be able to see the progress like it is possible when using CI servers like CruiseControl.NET (CCNET).

I started looking at the problem from a wider perspective – what we really need is a distributed CI system which would be able to provide control and monitoring of CI builds from a single point. This is opposed to how things are done with CCNET – you have to set up a separate project for each stage of the CI build and you also have to install separate instances of CCNET on each server that is a part of the build configuration (main build server, integration server, database server etc.). This makes setting up CI for a project quite time consuming.


So what would this CI system have to have to be useful:

  • CI process should be treated integrally: if the CI process consists of several stages (some of which may run in parallel or even on different computers), it should be treated as a single unit (internally separated into several stages). The configuration would specify the CI workflow and then the CI system would take care of all the necessary wiring. That doesn’t mean that you wouldn’t be able to get the feedback for each individual stage, if you wanted.
  • A single configuration point: the configuration for all of these stages should be located in a single place (in the main build service, let’s call it a Controller), not spread out over several computers.
  • Native support for version-controlled CI project configuration file(s): the Controller should only have to have the basic configuration (like how to fetch files from the version control system (VCS)). The rest of the CI configuration would be retrieved from VCS and thus could be dynamically updated with each new version.
  • A single monitoring point: the Controller would have to provide some kind of Web user interface which would display the status of the CI process (including statuses for all of the CI process’ stages on all other servers). The UI would have to be simple, just displaying raw build outputs (although the support for CCNET-like XSLT transformations could be provided).
  • Minimum installation and configuration friction: all of the CI system’s components should be able to run with minimal prerequisites. Edit the configuration file and run the Controller executable from a command line – this should be enough. I’m thinking about an integrated Web server (so no extra Web server installation would be needed) and automatic pushing of CI Agents to all of other servers which are part of the CI process.
  • Support for automatic deployment: the ability to remotely deploy and run software (the essence of yesterday’s post) as part of a CI process stage should be intrinsic. 

This ends my brainstorming session for today.

Published by breki on 23 Jan 2008

A new release of BrekiLabeller (1.7)

Tobias Jahn sent me a patch code for BrekiLabeller which adds some new options for generating build and revision numbers. You can now generate both build number and revision number from a file. Also, the revision number can be generated by an external tool (this is similar to SvnRevisionLabeller).

You can download the new release from the project’s sourceforge page.

Published by breki on 14 Jan 2008

Keeping track of code comment warnings in your CC.Net builds


On the project I’m currently working on we are struggling to have all of public classes and methods documented. Since we haven’t been very disciplined doing that, we still have around 400 warnings related to code comments, which can be problematic since some more important warnings could be overlooked in this mass.

Since we already have CC.Net Statistics set up on our build server, I decided to use it to track compiler warnings so that we make sure their number not increasing with new builds. So here are instructions on how to set it up on your CC.Net build server.

(NOTE: we are using the old version of CC.Net Statistics which came before the codeplex project, so I’m not sure the same procedure applies to the new MSI-based version. I couldn’t make the new version run on our build server, I think it is probably because our CC.Net was installed manually and not using the MSI installation).

Okey, so the first thing to do is to tell CC.Net that your project should collect statistics about compiler warnings. Open your CC.Net project configuration file and find the <publishers> tag for the project. Insert the following XML code inside the <publishers> tag (it should be after the any <merge> publisher and before any <xmllogger> publishers):

<statistics> <statisticList> <statistic name=’Compiler Warnings’ xpath=’count(//*[contains (text(),”warning CS”)])’/> </statisticList> </statistics>

If you already have the statistics publisher, just add the warning statistics line.

After saving the file, CC.Net should reload the configuration and start recording the statistics for the future builds. Now we have to add graphs for compiler warnings in CC.Net WebDashboard. Open the webdashboard\javascript\GraphConfiguration.js file in the text editor and find “var _recentGraphConfigurations” array. There you have to defined a new “recent graph” by adding the following lines:

   graphName: "Compiler",
   dataSource: _recentStatistics,
   numXTicks: _numberRecentGraphXTicks,
   series: [
      { name: "Warnings", attributeName: "Compiler Warnings", color: "green" }

You can choose your own title and color, off course.

To include warnings graph in the summary graphs page, first an function calculating the average warnings has to be added to the “var _summaryConfiguration” array:

compilerWarnings: function(successfulBuilds, failedBuilds) { return average(successfulBuilds, "Compiler Warnings") },

Now we have to add the summary graph to the “var _historicGraphConfigurations” array:

   graphName: "Compiler",
   dataSource: _summarisedStatistics,
   numXTicks: _numberHistoricGraphXTicks,
   series: [
      { name: "Average Warnings", attributeName: "compilerWarnings", color: "green" }

After saving the file, don’t forget to restart the WebDashboard application in IIS (the easiest way is just to “touch” its Web.config file). After the next build, you should be able to see new graphs on your project statistics page.