Continuous Integration With Multiple Projects

posted on 2004-09-20 at 12:04:49 by Joel Ross

I got tired of seeing a failing build every time I checked in a file for our Tourney Logic build server, especially when it wasn't what I was working on that was failing. It was another project altogether that I'm just getting started into how to build the installer automatically. I switched gears, so it's in an unfinished state (meaning, the build fails!).

Anyway, every time I checked in a file for the Tourney Bracket Control 2.0 (yes, we have finally started development on it!), I got a notice saying the build failed, when I knew it hadn't. So I decided to take some time to see how to set up multiple projects in CruiseControl.NET.

I'm only going to talk about the changes needed to go from a single project to a multiple project, so if you want the background on a single project set up, read my post on setting up continuous integration.

The changes are fairly straightforward. In your ccnet.config file, under each project element, add the following element:

<state type="state" filename="project1.ccnet.state" />

Make the state file unique for each project you want to track. If you have an existing build process, using new state files will cause the build number to start over. The state file tracks the build number, as well as the state of each build (pass or fail). Each project will now get it?s own URL too, so you?ll have to make the webUrl element unique too. Now each project can watch different folders in your repository, meaning a check in in one folder will not cause a build in another project not relying on that folder.

Now that brings up a question I had, and later found the answer to: What if you have two projects that share a library, and you want each to monitor that folder as well as the project?s folder? The way I have it working now is that I monitor the root folder. Here?s my folder structure:

/CurrentCode
  /Project1
  /Project2
   /SharedLibrary

So both projects monitor the CurrentCode folder. The advantage I get is that if Project2 is broken, Project1 knows nothing about it, but the disadvantage is that if Project2 has a file checked in, Project1 still builds. There?s a solution I?ll present, but note that I haven?t tried it, so I can?t verify that it works. Make your sourceControl element look like this:

<sourceControl type="multi">
  <sourceControls>
    <vault>
      <executable>C:\Program Files\Sourcegear\Vault client\vault.exe</executable>
      <username>[UserName]</username>
      <password>[password]</password>
      <host>www.mydomain.com</host>
      </repository> DefaultRepository</repository>
      <folder>$/CurrentCode/Project1</folder>
      <ssl>False</ssl>
    </vault>
    <vault>
      <executable>C:\Program Files\Sourcegear\Vault client\vault.exe</executable>
      <username>[UserName]</username>
      <password>[password]</password>
      <host>www.mydomain.com</host>
      </repository> DefaultRepository</repository>
      <folder>$/CurrentCode/SharedLibrary</folder>
      <ssl>False</ssl>
    </vault>
  </sourceControls>
</sourceControl>

I'll probably make this next week, so when I do, I'll let you know if it works. Basically, you are telling CC.Net to monitor more than one folder, allowing for more granular control over what gets built. Under the new method, if a file is checked into the /CurrentCode/Project1 folder, Project2 would not be rebuilt. This (to me) is a much better plan.

One note here: If you do have projects that share a component, and both projects build that component, make sure to stagger the build timing. I did this by modifying the modificationDelaySeconds to stagger the delay that CC.Net uses. We discovered this issue when one of our projects kept failing because the .pdb file could not be written to - because another project was using the same file at the same time.

The rest of the changes are for the web sites. Here's my new web folder structure:

/Builds
  /Project1
  /Project2
  /Dashboard

Each of the subfolders is an IIS application. Project1 and Project2 are copies of the CC.Net web folder. A couple of changes need to be made in conjunction. The web.config file's appSettings section for Project1 looks like this:

<appSettings>
  <add key="logDir" value="log" />
  <add key="ServerLogFilePath" value="C:\Inetpub\wwwroot\Builds\Project1\log\ccnet.log" />
  <add key="ServerLogFileLines" value="50" />
</appSettings>

The changes to make with this are in the ccnet.config file. There are two changes. First, in the publishers section, the logDir needs to match the web.config log file. The other change to remember to make is to change the projectUrl in the email section. Make sure it points to the Builds/Project1 folder.

The Dashboard folder is a copy of the webdashboard folder. If you don't change the port that CC.Net reports on (by default 21234), then the dashboard's web.config file can be left untouched. Otherwise, update appSettings section to reflect the correct port.

That?s it! You can now run multiple projects with the same CC.Net installation. And they can even depend on shared parts without affecting each other.

Categories: ASP.NET