I have implemented Dependency Management into Cruise Control that I would like to submit a patch for. I’m not sure what patch formats you except so for now I will just link to the zip file containing the changed and added source files. You can find the link here: http://members.gamedev.net/managedworld/downloads/CruiseControlPatch.zip. These changes are based upon version 0.8.0.822 pulled directly from CCNetLive.
The essence of the change is to allow the configuration of projects as such:
<name>A Failing Project</name>
The ramifications for a project with dependencies are as follows (the behavior, that is):
1) If a dependent project is currently building, wait until the dependency is finished building (the project activity will show “WaitingForDependencies” on the web dashboard while in this stage)
2) If a dependent project is in a failed state, then this project will fail also (with a “DependencyFailure” state to differentiate from a normal “Failure” state)
The ramifications for a project that is depended upon are as follows:
1) If I just finished building or I’m in a failed state, kick off builds for any projects that are dependent upon me
a. If I failed, kicking off projects dependent upon me will cause them to fail with a “DependencyFailure” state to catch dependency issues as soon as possible
This functionality addition will also, possibly, circumvent the need for a SingletonBuilder since the root cause of needing a SingletonBuilder was because there was no concept of “dependencies” in the build system.
The new files are all in the core project:
IProjectIntegratorRunner.cs and ProjectIntegratorRunner.cs are just class extractions of functionality that was implemented in the CruiseServer. This was done so that we can reuse this functionality (kicking off Project Integrators that is) from the Dependency Manager as well to kick off builds that are dependent upon the current project.
There are many other files that were touched due to a method signature change of IIntegratable.
I have also added unit tests to these new classes so that they should be relatively easier and ready to plug in to the trunk of the project.
Obviously, you can tell that this is not actual detailed dependency management, but it certainly has helped making my build process better at home, especially regarding having common codebases that are shared at code-level, rather than binary-dependency level, in order to achieve a true refactoring space among several projects.
I have submitted this to the mailing list for CruiseControl.NET in hopes that it will be integrated into the trunk of the project. If I hear anything more from them, I will be sure to give updates here.