please do ;-) On Fri, Jun 26, 2009 at 4:00 PM, CinnamonDonkey < [email protected]> wrote:
> > 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 >
