Hi What I would do is the following Platform1-Dbg on succes force build Platform1-Release on success foce build Platform2-Dbg on success force build Platform2 Release
so in the publisher section of Platform1-Dbg set the force build publisher to Platform1-Release in the publisher section of Platform1-Release set the force build publisher to Platform2-Dbg and so on http://confluence.public.thoughtworks.org/display/CCNET/ForceBuildPublisher with kind regards Ruben Willems On Fri, Jun 26, 2009 at 12:07 PM, CinnamonDonkey < [email protected]> wrote: > > 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 >
