CruiseControl.NET / Custom Plug-ins
I must admit, I’m a bit of a CruiseControl.NET fan. It drives most of our automation systems, and provides us a backbone from which we can hang many different systems. I use it both here at the Company, and when I’m doing tools consulting with other teams. That said, it’s not without it’s flaws and limitations; not least of which is the lack of documentation on custom plug-ins.
There are a wide variety of pre-built plug-ins already available, for source control systems like Perforce and Subversion, and build systems like Nant and MSBuild. These usually work pretty well straight out of the box, if you’re building a vanilla continuous integration server. That is, every change made to source control results in a build of some sort. I’m not going to dwell on why that’s a good idea (it is), I’m only going to say that there are times when you need something different. There are inelegant ways around this, but in truth CC.NET has all of the customisability to let you do this properly within the system – by defining your own plug-ins.
Reading the documentation on CC.NET, you get only a single page of documentation on custom plug-ins, and that page is pretty spotty at best. It shows you a “hello world” plug-in, with no clues as to what information you get into the plug-in, when your plug-in’s methods will be called, or how you’re supposed to pass either status information or logging back to CC.NET itself. In short, it’s pretty useless, other than to highlight that the facility is there, and give you enough of a pointer to get you into the code and poking around.
Sure enough, with Auto-complete on, you find that there are lots and lots of information passed to you, and by debugging and breakpointing inside your plug-in, you can get a feel for when your code is called. Making CC.NET load and unload your plug-in is refreshingly easy and fairly robust, and once you figure out how to pass parameters to your plug-in by specifying them in the config file, you can see the possibilities open up. More importantly than the sample building plug-in though is that, through a bit of digging, you find you can also define your own custom source control plug-ins, and with the combination of those two things, you can do pretty much anything you want.
In one particular situation, I’ve been working with a Perforce (p4) source control system, and a rather black-box build system for the game itself. Rather than wanting a build made of every single commit to the p4 repository, I needed it to make only particular builds – those marked as verified by the developer’s internal test team. This is a pretty common situation when you’ve got an automated build system – you have a raw source control system that lies underneath, which operates at the level of atomic commits. But above that is a logical structure, which only people understand – that operates at the level of ‘nightly builds’ and milestones. You have custom logic which you can apply to the system, using some basic rules. So in essence you have a virtual source control system, built on top of the raw version. By writing a custom source control plug-in for CC.NET, you can expose an interface to your automated build server, so that it recognises when something new is available from that virtual source control, and only builds exactly what you want.
CC.NET offers great flexibility, and those people who develop it, know all about that flexibility. But information on what you can do, and how, is rarer than hens teeth. So over the next few weeks, I’m going to write up and publish here some examples of real-world plug-ins that I’ve written. That should hopefully give readers enough context to go off and write their own plug-ins, to suit their own needs.
Disclaimer: all of the points made here refer to CruiseControl.NET 1.4.x, not the later versions of the system. There are some big and eagerly awaited advancements in the newly released 1.5 version, that many people like myself will have to avoid for now, until it’s bedded in.