Reusing Cruise Control .Net Configurations on the Same Instance

The sources described in this post can be downloaded here.

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:

<?xml version="1.0" ?>
<project name="name-release" workingdir="workingdir for release">
    <svn url="svnurl" username="username" password="password" />
    <msbuild script="buildscript for release" arguments="buildargs for release" />
</project>

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:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text" media-type="text/plain" version="1.0" encoding="utf-8" indent="yes" omit-xml-declaration="yes" />

<xsl:variable name="localprojectname"><xsl:value-of select="/project/@name" />-<![CDATA[&]]>serverDescription;</xsl:variable>

<xsl:template match="/">
    <xsl:apply-templates />
</xsl:template>

<xsl:template match="project">
    <project>
        <xsl:attribute name="name"><xsl:copy-of select="$localprojectname" /></xsl:attribute>

        <workingDirectory><xsl:value-of select="@workingdir" /></workingDirectory>
        <webURL>http://<![CDATA[&]]>serverAddress;/ccn
et/server/local/project/<xsl:copy-of select="$localprojectname" />/ViewLatestBuildReport.aspx</webURL>
        <triggers>
            <intervalTrigger name="continuous" seconds="30" buildCondition="IfModificationExists"/>
        </triggers>

        <xsl:apply-templates />

        <publishers>
            <merge>
                <files>
                    <file>C:\Projects\Reports\<xsl:copy-of select="$localprojectname" />.NUnit-result.xml</file>
                    <file>C:\Projects\Reports\<xsl:copy-of select="$localprojectname" />.FxCop-result.xml</file>
                    <file>C:\Projects\Reports\<xsl:copy-of select="$localprojectname" />.NCover-result.xml</file>
                    <file>C:\Projects\Reports\<xsl:copy-of select="$localprojectname" />.NCoverageReport.xml</file>
                </files>
            </merge>
            <xmllogger>
                <xsl:attribute name="logDir">C:\Program Files\CruiseControl.NET\Logs\<xsl:copy-of select="$localprojectname" /></xsl:attribute>
            </xmllogger>
        </publishers>
    </project>
</xsl:template>

<xsl:template match="msbuild">
    <msbuild>
      <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
      <projectFile><xsl:value-of select="@script" /></projectFile>
      <buildArgs><xsl:value-of select="@arguments" /></buildArgs>
      <targets>Build</targets>
      <logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
    </msbuild>
</xsl:template>

<xsl:template match="svn">
    <sourcecontrol type="svn">
        <workingDirectory><xsl:value-of select="../@workingdir" /></workingDirectory>
        <trunkUrl><xsl:value-of select="@url" /></trunkUrl>
        <executable>c:\build_tools\svn\svn.exe</executable>
        <username><xsl:value-of select="@username" /></username>
        <password><xsl:value-of select="@password" /></password>
    </sourcecontrol>
</xsl:template>

</xsl:stylesheet>

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:

<!DOCTYPE cruisecontrol[
    <!ENTITY serverDescription "WinXP">
    <!ENTITY serverAddress "xpmachine.mybuildservers.com">
    <!ENTITY myprojectrelease SYSTEM "http://localhost:2093/Default.aspx?source=release.xml">
    <!ENTITY myprojectdev SYSTEM "http://localhost:2093/Default.aspx?source=debug.xml">
]>
<cruisecontrol>
    &myprojectrelease;
    &myprojectdev;
</cruisecontrol>

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.

<%@ Import Namespace="System.Xml" %>
<%@ Import Namespace="System.Xml.Xsl" %>
<%@ Import Namespace="System.Xml.XPath" %>
<script language="C#" runat="server">
    public void Page_Load(Object sender, EventArgs e)
    {
        string xmlPath = Server.MapPath(Request.Params["source"]);
        string xslPath = Server.MapPath("configuration-template.xsl");

        XPathDocument doc = new XPathDocument(xmlPath);
        XslTransform transform = new XslTransform();
        transform.Load(xslPath);

        StringBuilder builder = new StringBuilder();
        XmlWriterSettings settings = new XmlWriterSettings();
        settings.Indent = true;
        settings.CheckCharacters = false;
        settings.NewLineHandling = NewLineHandling.None;
        settings.OmitXmlDeclaration = true;
        settings.Encoding = Encoding.UTF8;

        using (XmlWriter writer = XmlTextWriter.Create(builder, settings))
            transform.Transform(doc, null, writer);


  builder.Replace("&amp;serverDescription;", "&serverDescription;");
        builder.Replace("&amp;serverAddress;", "&serverAddress;");

        Response.Write(builder.ToString());
   }
</script>

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:

<cruisecontrol>
    <project name="name-release-WinXP">
        <workingDirectory>workingdir for release</workingDirectory>
        <webURL>http://xpmachine.mybuildservers.com/ccnet/server/local/project/name-release-WinXP/ViewLatestBuildReport.aspx</webURL>
        <triggers>
            <intervalTrigger name="continuous" seconds="30" buildCondition="IfModificationExists" />
        </triggers>
        <sourcecontrol type="svn">
            <workingDirectory>workingdir for release</workingDirectory>
            <trunkUrl>svnurl</trunkUrl>
            <executable>c:\build_tools\svn\svn.exe</executable>
            <username>username</username>
            <password>password</password>
        </sourcecontrol>
        <msbuild>
            <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
            <projectFile>buildscript for release</projectFile>
            <buildArgs>buildargs for release</buildArgs>
            <targets>Build</targets>
            <logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
        </msbuild>
        <publishers>
            <merge>
                <files>
                    <file>C:\Projects\Reports\name-release-WinXP.NUnit-result.xml</file>
                    <file>C:\Projects\Reports\name-release-WinXP.FxCop-result.xml</file>
                    <file>C:\Projects\Reports\name-release-WinXP.NCover-result.xml</file>
                    <file>C:\Projects\Reports\name-release-WinXP.NCoverageReport.xml</file>
                </files>
            </merge>
            <xmllogger logDir="C:\Program Files\CruiseControl.NET\Logs\name-release-WinXP" />
        </publishers>
    </project>
    <project name="name-dev-WinXP">
        <workingDirectory>workingdir for dev</workingDirectory>
        <webURL>http://xpmachine.mybuildservers.com/ccnet/server/local/project/name-dev-WinXP/ViewLatestBuildReport.aspx</webURL>
        <triggers>
            <intervalTrigger name="continuous" seconds="30" buildCondition="IfModificationExists" />
        </triggers>
        <sourcecontrol type="svn">
            <workingDirectory>workingdir for dev</workingDirectory>
            <trunkUrl>svnurl</trunkUrl>
            <executable>c:\build_tools\svn\svn.exe</executable>
            <username>username</username>
            <password>password</password>
        </sourcecontrol>
        <msbuild>
            <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
            <projectFile>buildscript for release</projectFile>
            <buildArgs>buildargs for dev</buildArgs>
            <targets>Build</targets>
            <logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
        </msbuild>
        <publishers>
            <merge>
                <files>
                    <file>C:\Projects\Reports\name-dev-WinXP.NUnit-result.xml</file>
                    <file>C:\Projects\Reports\name-dev-WinXP.FxCop-result.xml</file>
                    <file>C:\Projects\Reports\name-dev-WinXP.NCover-result.xml</file>
                    <file>C:\Projects\Reports\name-dev-WinXP.NCoverageReport.xml</file>
                </files>
            </merge>
            <xmllogger logDir="C:\Program Files\CruiseControl.NET\Logs\name-dev-WinXP" />
        </publishers>
    </project>
</cruisecontrol>

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 🙂

5 Replies to “Reusing Cruise Control .Net Configurations on the Same Instance”

Elad says:

July 6, 2008 at 9:19 am

Thanks! This is very interesting. I think I’ll use this technology with some tailoring to our specific needs. I’ll let you know when I get some results.
karlagius says:

July 6, 2008 at 10:57 am

Glad it helped! Let me know if there are any issues, or if you have any suggestions to add to it 🙂 Thanks for your feedback!
gerald says:

December 5, 2008 at 10:00 pm

wow, very interesting! i agree that it is quite roundabout; it’s a shame that seems cruisecontrol.net doesn’t support some kind of sharing of options between similar projects (or multiple branches of the same project).
NIck says:

February 10, 2010 at 9:39 pm

This is much easier accomplished by using the Configuration Preprocessor, to define defaults that can be reused, and/or to create nested s that define common project properties and overwrite with configuration specific changes.

See http://confluence.public.thoughtworks.org/display/CCNET/Configuration+Preprocessor
1. Karl says:
  
  February 11, 2010 at 1:59 am
  
  Good tip – thanks Nick 🙂

Comments are closed.