One of the problems I currently have with CruiseControl.Net is that some of my tests spawn multiple processes; such as server tests which run the development environment, which runs a batch file to start a server (or two) and then run a test harness which generates network traffic and then run a program to ask the server to shutdown cleanly. When these tests timeout in CC.Net they’re forcibly killed. Unfortunately due to how Windows processes work, killing the parent of a tree of processes doesn’t kill the children.
Here is another patch for CruiseControl.Net. This patch provides support for a Robocopy SourceControl provider. This gives a significant performance increase over the FileSystem SourceControl provider. To integrate this I needed to adjust how CCNet determined if an executable had succeeded, it used to rely on the exit code of the executable being 0 to indicate success, but Robocopy is more complex than that.
ProcessExecution-MultipleSuccessExitCodes-Patch.txt
And here are the source files and test harness for the robocopy source control provider.
I’m continuing to tune my continuous integration system. Today I switched the ‘deploy’ projects from using a CC.Net file system source control task to do the deployment to using Robocopy. This has sped things up nicely and made the deployments more configurable. One problem that I had was that the CC.Net “executable” task (the one that lets you run arbitrary executables) assumed that only exit codes of 0 were ‘success’ and Robocopy has a more complex strategy for exit codes (see here).
Yesterday I mentioned that the file system source control provider in CC.Net was a little inefficient. I speculated as to how it might be working and how it might be improved. Well, as the saying goes, assume makes an ass out of you and me…
The file system source control provider is actually far far simpler than I expected. It scans the ‘repository’ file system tree and simply looks for files that have been written to since the last check.
Well, it’s about a month since I started running Cruise Control .Net and things have settled down somewhat now and I can almost go a day or two without tweaking my configuration or being tempted to fix issues in Cruise Control itself.
For those of you that haven’t been following along:
First I realised that the latest (1.3) release of Cruise Control .Net wouldn’t work for me without some hacking.
Hacking CruiseControl.Net to work better for my specific circumstances (lots of projects that depend on lots of projects) has resulted in the following patches to revision 3607 of ccnet which I’m just about to submit to the developers.
These patches are ‘supporting patches’ to the main ProjectTrigger and integrator changes, I thought I’d start with the simple ones… None of these patches should change existing functionality, all require new, optional, properties to be specified to activate the new code.
I hacked another fix into CruiseControl.Net today and we now almost have an acceptable level of performance in my particular (some may say warped) circumstances. The trick was to hack the project trigger to be a “local project” trigger. By default the project trigger uses .Net remoting to talk to the CruiseControl.Net server where the project is hosted. In my case this meant that all of my project triggers (and there are lots!
I am intending to check out some of the other build servers that people have been suggesting, but today I was too busy with real work so I just left a cut down version of my latest CruiseControl.Net configuration running on one of my boxes and fixed a few issues whilst doing proper work most of the time… This evening I decided to go and look at why CruiseControl.Net scales so poorly and the first issue that I came across is the title of this blog posting…
I’ve almost got something that works out of CruiseControl.Net. Once I’d hacked in some fixes for the project triggers and other stuff that didn’t work the way I wanted it to I concentrated on generating the config files that I required and testing the system.
The good news is that I now have an integration system that works, it can build, test and deploy libraries in such a way that dependent libraries and applications are rebuilt as new versions of deployed artifacts become available.
I’ve been trying to get my code to build with CruiseControl.Net this week. It’s taken longer than I’d hoped, but I’m almost there. It became easier when I switched from assuming various parts of CruiseControl.Net would “work as I expected them to” to assuming that I’d have to delve into the source and change things…
On the whole I’m a bit disappointed in CruiseControl.Net. I’m sure it works very nicely for simple situations, such as where you pull everything out of your repository and build it with a single project, but, when you’re trying to do more complex things it seems to be a bit fragile.
