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
>>>
>>>
>>>
>

Reply via email to