Homepage ->  Individual Weblogs -> Jeffrey Fredrick  -> CruiseControl 2.6.1 Released

March 05, 2007 - CruiseControl 2.6.1 Released

Last week CruiseControl 2.6.1 was released. In this release there are several bug fixes but also an odd little plug-in that seeks to address a common problem with inter-project dependencies. Read on to learn about the new Veto plug-in and how it can help keep your projects building in the correct order.

The Veto source control was created to address a common scenario: Project B depends on Project A, but when a commit is made against both A and B it is quite likely for Project B to build first, with the build failing only because the changes in Project A haven't been built yet. Another common failure mode is that Project A builds first but the build fails either due to a compile error or a test failure, and then Project B attempts to build before that problem could be resolved. In either case the result is a spurious failure email sent to the team, and if this happens often enough it can desensitize them to real failures.

So how does Veto help?

The idea is simple. The Veto plug-in will check to see if a given target project is up to date with the latest changes provided by some other source control, and if not, will Veto the current build attempt. In the scenario mentioned above this would mean that Project B would use the Veto to see if Project A was up to date, and in the cases where Project A is out of date then Project B will not build.

Here's an example of configuring the Veto source control:

<project name="ProjectB">

  <modificationset>
    <veto>
      <triggers>
        <cvs localworkingcopy="work/ProjectA"/>
      </triggers>
      <buildstatus logdir="logs/ProjectA"/>
    </veto>

    <cvs localworkingcopy="work/ProjectB"/>
  </modificationset>

  ...
</project>

So when Project B is going to build it will check to see if there are any changes in Project A and then check the build logs for Project A to see if there has been a successful build of Project A since those modifications were made. If there are unbuilt changes or if the project wasn't built successfully then the current build attempt by Project B will be vetoed (skipped) until Project A is brought up to date.


Posted by Jeffrey Fredrick at March 5, 2007 10:47 AM


Trackback Pings

TrackBack URL for this entry:
http://www.developertesting.com/mt/mt-tb.cgi/239


Comments

A more general way of doing this (particularly with one CruiseControl instance, or a communicating zeroconf cluster) would be to actually ask the other project to do a modificationset check. It could then say if it _needs_ to build, and if it does, you wait.

CruiseControl has come a long way working with "disconnected" projects, but as we move up to more complicated build structures, more sophisticated needs are present.

I'm seriously thinking about building this to work with the maven2dependency snapshot (imagine 40+ small modules being built into 3 separate EARs, and the resulting buildfest triggered when you commit to something at the bottom of the layer)

Posted by: Robert on March 5, 2007 02:30 PM

I've had similar thoughts myself Robert. In my version I was thinking of a dependency aware "project" that would hold nested projects in the way that several of the publisher or source controls nest other plug-ins of the same type, and have info about the relationships between the projects. Then it could ask each of the projects if they needed to build and from the answers invoke a series of builds in turn.

Posted by: Jeffrey Fredrick [TypeKey Profile Page] on March 5, 2007 07:20 PM