Hi Brendan, Thanks for the reply. Alas, integration queues are pretty much the cause (in as good a way as possible) of my issue!
We have 6 queues, but one of those queues is designated as "System" and contains 2-3 tasks which really should block all other queues. What you have opened my eyes to though, is that what WOULD fix my problem would be if I could mark projects as belonging to more than one queue (e.g. queue='queue_1' lockQueues='queue_2, queue_3' or similar). This leads me back to my original supposition that no method to implement the mechanism I want currently exists - but does anyone out there feel there would be value in my submitting this as a patch, rather than just putting a local fix in place? Cheers, Matt Chatterley 2008/8/29 Brendan Crosser-McGay <[EMAIL PROTECTED]> > I'm not sure if this is what you want, considering this is a per-project > queue, not a per Nant task queue, but would the ccnet integration queues > help to separate out some of your tasks? > > http://confluence.public.thoughtworks.org/display/CCNET/Integration+Queues > > I know they helped us to fix some parallel build conflicts. > -Brendan > > > On Wed, Aug 27, 2008 at 11:38 PM, Matt Chatterley < > [EMAIL PROTECTED]> wrote: > >> Corey, >> >> Yeah - thats essentially the problem - essentially using a folder >> structure as source control (well, as far as CCNET/Nant are concerned) isn't >> ideal. >> >> In terms of achieving a solution via triggering, the only option I really >> saw is filterTrigger, and the confluence docs on that one strongly imply >> that it is literally used to prevent a build from happening (e.g. ignore >> changes made when filter conditions are met) - which isn't really what I >> want to do! >> >> A _crude_ approach (not implementation specific), would be at the start of >> each build to check a lock e.g: >> >> 1. Start Build script >> 2. Check if "VSSLock" has already been acquired by another process >> 3. If yes, wait N millis and re-check >> 4. If no, and I am the VSS process, acquire it and run, else run without >> acquiring it >> >> As you can see - close to sequential projects but subtly different, in >> that I want all products to wait on a lock, but only one product (possibly >> 2) to acquire the lock when they run! >> >> >> Cheers, >> >> Matt >> >> 2008/8/28 Corey Graham <[EMAIL PROTECTED]> >> >> >>> Is your vss task in it's own build project? You could set up triggering >>> so other builds don't run unless that one is completed. The issue seems to >>> be that this task is operating on a dir structure also scanned for changes >>> by another build. You need to find a way to separate them. >>> >>> >>> >>> >>> Sent from my iPhone >>> >>> >>> On Aug 27, 2008, at 3:59 AM, "Matt Chatterley" < >>> [EMAIL PROTECTED]> wrote: >>> >>> Hello all, >>>> >>>> I've seen threads on similar topics to this, however haven't been able >>>> to >>>> find anything extant thus far which meets our precise requirement. >>>> Hence, >>>> before I launch into creating a custom solution, I thought I would ask >>>> for >>>> any ideas/suggestions/pointers to existing tools. >>>> >>>> We use CCNET - primarily with NAnt and VssConnect. >>>> >>>> To cope with a few facets of our build set up (e.g. no plugin currently >>>> exists for VssConnect as is, no time currently to write one either!) >>>> plus >>>> the fact that our build server is quite low spec, we use a build task >>>> executing a NAnt script to update a local folder, which serves as our >>>> source >>>> repository for builds - this is monitored by CCNET, which starts builds >>>> accordingly. >>>> >>>> This is fine, however, occasionally the processes clash, and something >>>> builds while the 'VSS Cache' task is running, which can cause failures >>>> (especially since every 10th or so update intentionally deletes and >>>> recreates the cache to ensure it is kept healthily in sync). >>>> >>>> What we want to do is to lock around this task - the existing sequential >>>> task plugin would allow us to create locks around such things, however, >>>> we >>>> use a number of build queues to allow parallel building, and want to >>>> keep >>>> this - having read the docs on sequential tasks, we'd have to put a lock >>>> wrapper into all tasks to prevent clashing with VSS Update, which would >>>> essentially bring us back to no parallel builds. >>>> >>>> Does anybody know of an existing way to do this locking? Essentially the >>>> summary is: >>>> >>>> 1. Task A should not start until no other tasks are running >>>> 2. No other task should start until Task A has completed running >>>> 3. Tasks B, C, D (ad nauseum) should be able to run in parallel, if >>>> their >>>> queues permit, providing assertions 1 and 2 are both kept as true >>>> >>>> If nothing exists that can quite cope with this, I will be setting >>>> something >>>> up to do so - in that case, would anybody else be interested in this >>>> being a >>>> plug-in (or even contribution? I think it is too niche for that, though) >>>> to >>>> CCNET? If so, I will create it in this manner and make it publicly >>>> available >>>> - if not, I will just sort out something quick and in-house! >>>> >>>> >>>> Cheers, >>>> >>>> Matt Chatterley >>>> >>>> >>>> >> >
