What’s New in 1.4.4: Server Extensions

A Quick Intro

As well as a number of bug fixes, we’ve added some new functionality to 1.4.4. Most of this functionality as been around for a while, mainly in the security branch, so I thought I’d review some items. Over my next few blog posts I’ll look at some of the new items that have been added, and the possibilities they open up.

Expanding Expandability

One of the great things about CruiseControl.NET is its flexibility, and if the trunk distribution doesn’t contain what you want, it’s pretty easy to add your own extensions. The only real limitation is the allowed places for extensions – they are limited to being items in the configuration file (ccnet.config), like tasks, source control, triggers to name a few common ones.

With release 1.4.4 it is now possible to build a “global” extension to the server. These extensions have nothing to do with ccnet.config, instead they are added in the application configuration (ccnet.exe.config or ccservice.exe.config).

These extensions work at a deeper level than the older extensions. The older extensions had to work within the context of a build, they could affect the outcome of a build, but not how the actual server worked. The new extensions allow the actual functionality of the server to be modified!

Sounds exciting? I certainly think so!

Some Possibilities

These extensions now allow developers to influence how the server works, and allows developers to open new channels to the server.

As an example, currently in CruiseControl.NET there are projects and there are queues. It is possible to limit builds, but only by adding projects to a queue. If you wanted to limit the server so only five projects could build, no matter which queue, you were in trouble! Now with server extensions, we can build an extension to allow only five projects to build, no matter which queue they are in (and yes, I have built it).

A second possibility is to extend the logging. For example, an administrator might want to record all the force builds, or maybe just the number of times a project is stopped and started, or how often builds are triggered. Currently, they’d have to go through the log (assuming the correct log level is set) and manually count all the instances. Now, we could build an extension that just counts the number of force builds, stops, starts, etc. (sorry haven’t written this one yet).

The third possibility I can think of is with communications. Currently there is only one communications channel to the server – .NET Remoting (yes, there is HTTP, but this goes via the dashboard and still uses .NET Remoting to connect to the server). The new extensions now allow us to add any types of communications channels we want. I’ve built a simple one that uses WCF as the underlying channel, the only hard part was translating the objects – since I couldn’t add the WCF serialisation attributes to the existing types.

Time to Code

I’ve listed a few possibilities for the new server extensions, over time I’ll try to implement these and add a few more options to the list.

If you want to try and build an extension, I’ve started on the documentation (http://confluence.public.thoughtworks.org/display/CCNET/Server+Extensions), although I still need to work on it. In a nutshell, ThoughtWorks.CruiseControl.Remote.ICruiseServerExtension must be implemented (it only has four methods) and then the extension registered in the application config.

So have a play, let me know what you think. Also, I’m open to any ideas for extensions – just send me the idea and I’ll take a look at it.

Happy coding…