Reusing Cruise Control .Net Configurations on the Same Instance
This post follows up from my previous post, Configuring Projects on Multiple Instances of Cruise Control .Net. In one of the comments to this post, Elad asked if it was possible to reuse configuration files on the same instance of Cruise Control.Net. This would make sense in scenarios where you want to keep different branches of the same project integrated on the same machine without re-defining all the configuration for each. While this makes perfect sense, I couldn’t find any way to do this directly, so I tried to come up with a workaround that allows this. Please bear this in mind while you read the rest of this post. My knowledge of XML in general and Cruise Control configurations in particular is neither all-encompassing nor flawless in its brilliance, so there are probably, oh, a few million holes you could poke into this method. That said, I’m always open for comments, so if you have a better way, please share it 🙂
In order to allow some sort of parameterization of the configurations, we’re going to introduce a middle man. This will take the form of an asp.net page, and will take an XML file containing details specific to the build, and transform it (via XSLT) into a full project element.
The XML files we will use are fairly simple things – this is an important point, because these are the files that we’ll be creating most often. The files will be in the following format:
Note that we’ve tagged the name of the project with -release to indicate what sort of build this will be. The workingdir attribute will be used for the project working directory, and the svn checkout directory (that’s why there’s no checkout folder described in the svn element). The attributes for the svn and msbuild elements will be replaced into the equivalent elements in the project configuration.
The XSLT will take care of the boilerplate stuff, and stick in any build-specific information:
As you can see we’re still using the &serverDescription; and &serverAddress; entities which we defined in the previous post. These must still be defined in the main ccnet.config file of each build server. The entities defining the projects, however, should now reference our XSLT converter, rather than the file on the file system:
NOTE: The url specifies port 2093 because I was using the Visual Studio web server to test this code. The port should be whatever your asp.net server uses.
Now, the project configurations specify a url, passing the name of the configuration file to use as a parameter. The url should point to an asp.net page containing the following code; this will act as a converter. Note that the following assumes that the configuration files will be present in its own folder, not in the project folder.
NOTE: The builder.Replace(…) statements at the end are there because I couldn’t find a way to force the writer not to escape the & character; It kept getting pushed out as &
If everything is ok, Cruise Control should now see the file as follows:
Phew. Quite frankly it’s a rather roundabout way to get this done. If anyone has a simpler or cleaner way of achieving the same result, I’d be extremely happy to know how 🙂