Hello,
This "continuous integration pattern" you are describing can be summarize
like this:
"Having a unique project A in a separate retrieving queue which is
responsible for retrieving source file under source control and N projects
that actually build the software in N build queues"
This is indeed a pattern than cannot be applied with CCNet. For now you must
have the project A inside each build queues, it is overkill and in your case
it's too much time consuming.
The "Lock" feature can be a POWERFUL feature of CCNet for non-trivial
continuous integration patterns (which the best to my mind).
Moreover I would say we need a fake source control block which can import
source control block results from project A into each N build projects (with
this we'll have all the email and tracking features). Something like:
<ImportSCCResults>
<FromProject>project name</ FromProject>
</ImportSCCResults >
Cheers,
--Sylvain
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
