Sorry - bad discription on my behalf :( Drop the second quote - brain
and fingers are not in sync ;).

The first project runs an interval trigger:

        <triggers>
                <intervalTrigger name="continuous" seconds="60"
buildCondition="IfModificationExists" initialSeconds="60"/>
        </triggers>

All other projects run a project trigger:

        <triggers>
                <projectTrigger 
serverUri="tcp://localhost:21234/CruiseManager.rem"
project="PlatformN.Config">
                        <triggerStatus>Success</triggerStatus>
                </projectTrigger>
        </triggers>

Build order is not guaranteed.








On 26 June, 10:54, Ruben Willems <[email protected]> wrote:
> Hi
>
> I'm missing somehting
> <quote>
> Because each project is basically building the same code base, I
> configured the chain so that Platform1-Dbg monitors the SCM and only
> triggers IfModifications are detected. All other projects share the
> same working directory as Platform1-Dbg and are triggered via a
> project trigger.
> </quote>
>
> and
> <quote>
> Because  each project is free running on an interval trigger the order in
> which
> they appear in the build queue is not guaranteed.
> </quote>
>
> I would say : Platform1-Dbg has an interval trigger with iffmodifications
> the ohter only via the project trigger
>
> so what am I missing ?
>
> with kind regards
> Ruben Willems
>
> On Fri, Jun 26, 2009 at 11:44 AM, CinnamonDonkey <
>
> [email protected]> wrote:
>
> > Hi All,
>
> > Here is an interesting problem.
>
> > I have 4 projects configured and chained as follows:
>
> >   Platform1-Dbg --> Platform1-Release --> Platform2-Dbg --> Platform2-
> > Release --> DONE
>
> > Each project uses the same code base, but builds a different
> > configuration. The idea being that we are validating all supported
> > configurations for any changes to the code base.
>
> > They are configured as separate projects because each configuration
> > should maintain its own reports plus it is easier to tell which
> > configuration is failing.
>
> > If any stage of the project chain fails to build, then a build failed
> > email is generated for that project and the chain stops at that
> > point.
>
> > NOW for what I though was the clever bit!
>
> > Because each project is basically building the same code base, I
> > configured the chain so that Platform1-Dbg monitors the SCM and only
> > triggers IfModifications are detected. All other projects share the
> > same working directory as Platform1-Dbg and are triggered via a
> > project trigger. If the previous project in the chain is successful
> > then build. We don't need to re-get the source because we already have
> > it thus saving time!
>
> > Have your spotted the problem?
>
> > We'll, this relates back to an issue I brought up long ago. Because
> > each project is free running on an interval trigger the order in which
> > they appear in the build queue is not guaranteed.
>
> > Thus you can get...
>
> > Platform1-Dbg --> Platform1-Release
> > Platform1-Dbg
> > Platform2-Dbg
> > Platform1-Release
> > Platform2-Release --> DONE
> > Platform2-Dbg --> Platform2-Release --> DONE
>
> > and many other nasty combinations :(
>
> > Is there anyway to guarantee build order?
>
> > Cheers,
> > Shaun

Reply via email to