CruiseControl.Net... Serialised Build Queues
As a little break from NCoverExplorer development I started dabbling last weekend with the CruiseControl.Net source code. A disclaimer up front - this is all at the experimental stage and subject to further approval by the CC.Net project admins but it looks promising so far...
The main problem I am trying to resolve is the situation where you want to prevent two projects from running at the same time. Why would you want to do that? Perhaps you have resource constraints like a file system directory or a database the unit tests run against. For instance we have separate projects for continuous and daily builds - without a locking mechanism we likely get a failed build if they both run at the same time (one may do a "clean" while the other is trying to "build" etc).
A useful plugin was developed recently by Richard Hensley available from here to implement a locking mechanism which does help solve this. However it has a few limitations due to being a plugin which are best overcome by changing the CruiseControl.Net source code (in my opinion anyways). Various other implementations I have seen or even developed myself using mutexes or lock files all have similar issues.
What sort of limitations? As a build manager and developer I want visibility of the build queues, the ability to cancel pending items on the queue and to more granularly control the order that things get built.
My first stab of this is still a work in progress but looks like this...
1. You can optionally add a "queueName" attribute to each <project> node to force projects into a serialised integration queue. If you don't specify a queue the project will have it's own queue of the project name - effectively the same behaviour you have now.
2. You can also optionally add a "queuePriority" attribute to control the order of pending integrations on the queue. A priority of zero (default) just means build in the order placed on the queue.
3. A new optional panel in CCTray (see the demo gif below) to display the state of your queues across all polled servers. From CCTray you can right-click to cancel pending integrations provided they have not yet started.
4. A new web page plugin to allow web-based viewing of the queues and cancel pending integrations. Still to be developed.
Here's a little taster of what it looks like at the moment...
Comments, suggestions and feedback welcomed... there is a thread for this on the ccnet-devel Google newsgroup.
[Update: 22nd-Jun-07 This patch has been integrated into the CruiseControl.Net 1.3.0 release now publicly available]
Filed in: CruiseControl.Net
posted by kiwidude @ 9:20 pm
5 comments
5 Comments:
Sound VERY interesting!
I've being using Richard's plugin for a while now, and was really concerned that other developers can't see "pending" projects on the dashboard (only few of us are using CCTray), which leads me to the question: will this enhancement support for canceling pending build through the dashboard also, like you're showing that CCTray does (in the gif)?
great work Grant.
`Moshe
Hi Moshe - yes there is a plan to offer this option through the web dashboard as well. There are apparently a number of big changes proposed to the web dashboard by the admins so I will wait for the dust to settle on that before I get stuck in hopefully.
When we were discussing this on the list, I hadn't realized you had put a demo of the CCTray piece on the web. It looks fantastic! Very cool work.
Thanks for the nice feedback David.
I've submitted all the required changes except for the web dashboard to that JIRA CCNET-770 and it's in the hands of Owen and the other admins as far as I am concerned now. Obviously I will be delighted if they decide to run with it in some shape or form.
My fear is that getting a consensus of agreement on such a big change may be difficult. I can't argue the fact that it doesn't solve every problem with CC.Net that some developers are facing. Specifically those who want concurrency in their dependent projects - this solution is all about serialising conflicting builds.
I believe it does however address enough of the issues to give significant benefit immediately to people who have been battling with these issues since CC.Net began. I guess we wait and see what happens...
I think this patch does pretty much everything I need it to do for my company's build server. I've made some of my own patches to CCTray as well to fix some issues I have with it. The guys who run the CC.Net project seem to take forever to address fairly simple bugs and feature requests. I feel as though it would be in my own best interest to maintain my own CC.Net codebase.
Post a Comment
<< Home