Shared code libraries and cruise control testing

Question

I have 2 applications sharing a common library. Both apps and the library are in active development. Both apps include the project file in their solution.

The folders are laid out in source control as:

Root
  App1
  App2
  Library

We currently have separate cruise control builds set to run any time a file is committed to the app1, app2, or library folder hierarchies. A successful build of Library will then trigger builds of app1 and app2.

For the most part this works well; the problem is when someone commits changes to both Library and App1 (or app2). This generally occurs as a result of implementing a function that requires modification/addition to something in Library to be implemented. When this happens the triggers for building both Library (change in Library\foo.cs) and App1 (change in app1\bar.cs) will activate. Both will see that the file Base\Library\foo.cs has been changed and attempt to rebuild Library. Only one will succeed because the fire one to start writing an object file for Library will get an exclusive file lock; the second immediately fails. This has happened several times forcing someone to go in and manually rerun the build that failed due to the lock.

To try and mitigate the risk of this happening again we've changed the polling intervals for each of the triggers so that they're set to different values to try and avoid two firing at the same time. It's still not perfect because the cycles between Library and AppN will occur at the same time every N*M seconds (N and M being the respective polling intervals).

Is there a more elegant or less likely to fail solution available?

Answer 1

Yes. I believe you want to put all 3 projects in the same queue. This will prevent the projects from being built simultaneously.

You'll want something like this in your CCNet.Config file:

<project name="Library" queue="Q1" queuePriority="1">
<project name="App1" queue="Q1" queuePriority="2">
<project name="App2" queue="Q1" queuePriority="3">