Thank you Ruben - queuePriority worked a treat :) Shaun
On 26 June, 19:56, Ruben Willems <[email protected]> wrote: > yep > > On Fri, Jun 26, 2009 at 4:31 PM, CinnamonDonkey < > > [email protected]> wrote: > > > Does that mean I have to make all projects that can be forced a higher > > priority than projects that are on interval triggers? > > > On 26 June, 15:05, Ruben Willems <[email protected]> wrote: > > > Hi > > > > now that I think of it, I had this also at work > > > and my solution was the queue priority > > > > all projects in CI category ( with an interval trigger), have a priority > > in > > > the 900 range (900 - 999) > > > all projects in deploy category have a priority in the 200 range (200 - > > 299) > > > all projects in deployToTest have a priority or in the range 100-199 > > > all projects in the same Q > > > > so if there is a modification done, to the first project (Platform1-Dbg), > > it > > > will be pushed back until the chain has finished. > > > > with kind regards > > > Ruben Willems > > > > 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
