This is a good start but the "Force Build" seems to places the project being forced at the end of the queue (I'm observing other project building inbetween).
Could the force build be pre-emptive and jump the queue running before any other queued projects? or at least provide an option for this. It makes sense that these projects should run as a block, they are only split out for the sake of reporting and end user friendlyness but they should run together in context. Whats more...(I've just noticed) it seems that because the forced build is triggered in the publisher, if another interval trigger for the main starting project fires then it can be queued before the "force project publisher" build is queued. Now we're back to square one :( I can make up a JIRA for this. Shaun On 26 June, 11:41, CinnamonDonkey <[email protected]> wrote: > Ah-ha!!! - What a star! > > That sounds exactly like what I needs :) - I'll give it a go right > now :D > > Shaun > > On 26 June, 11:35, Ruben Willems <[email protected]> wrote: > > > 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/ForceBuildPub... > > > 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
