One question on the ApplyForceBuildsReplace/ReAdd scenario. Project A : Developer makes changes 1 and requests build.
Project A : After a while a different developer makes changes 2 and requests a build Project A : After more "a while" :) the third developer makes changes 3 and requests a build A1 B C A2 D E A3 Assuming that A3 does not have the changes of A2 (since they happened very quickly). Then with both the scenarios I would loose the changes of A2. If my project needs quick builds with independent control, I am better off with UseFirst. Is there a way to trigger the CCNet Admin that a build A3 has been called for but changes from a previous build request have not been merged ? Think about it, its interesting for the automated build process (that has features like ApplyForceBuildsReplace/ReAdd to notify the admin that things are getting screwed on the build queue. Debuging such a problem can become a nightmare for the CC admin. Regards Siddharth On Wed, Mar 11, 2009 at 1:32 PM, Ruben Willems <[email protected]>wrote: > Hi > > > the documentation is rather clear, > http://confluence.public.thoughtworks.org/display/CCNET/Queue+Configuration > > but here it goes ;-) > > duplicate tag : handles what to do when a project is more than once in the > queue, AND the project is a force build > > Scenario : when there are a lot of projects in the queue : > A B C A D E > > the first A is being built now, the second is waiting > > now suppose A is triggered again(forced), so it must be added to the queue > now the duplicate tag kicks in > > use first : just add A to the list > so the queue is like follows > A B C A D E A > > > ApplyForceBuildsReplace > A B C A D E > > A is not appended, because it is already in the queue, it replaces the > existing one > > ApplyForceBuildsReAdd > A B C D E A > > A is re-added to the queue, but the existing one is removed from it > > > > I hope I am 100% correct about this, I have not tested this > > with kind regards > Ruben Willems > > > > > On Wed, Mar 11, 2009 at 8:34 AM, jonty s <[email protected]> wrote: > >> <Adding ccnet-user too to get a perspective of real projects using >> queue's> >> >> So priority is more about sequencing the builds. Gotcha!! >> >> *Duplicate Tag* >> >> duplicates="UseFirst", why would someone configure duplicates ? So if >> incorrectly configure my build sequence I might get duplicate entries. To >> fix this contention we have duplicates to resolve contention. Right ? No >> other reason. >> >> If I have 2 projects in Q1 with the same priority, then it should flag a >> error right ? Since its not able priority, but sequencing instead. >> >> Why would someone want to use duplicates="ApplyForceBuildsReplace" OR >> duplicates="ApplyForceBuildsReAdd". Wont this result in a unpredictable >> state of the build ? >> >> *Lock Tag* >> >> Will the config catch a circular lock ? >> >> Why do we have lock's, dont priority handle the sequencing problem ? >> >> What if I lock B when running A, but instead prioritize B to run earlier >> than A ? Do we handle this circular deadlock ? >> >> Please advice >> >> Siddharth >> >> On Wed, Mar 11, 2009 at 12:23 PM, Matt Chatterley < >> [email protected]> wrote: >> >>> Hiya, >>> >>> I think Craig is right - queues definitely handle both of these, and were >>> implemented for a number of reasons - I certainly made some tweaks to them >>> for resource contention issues, too. :) >>> >>> Siddharth - what is the problem you are trying to solve? >>> >>> Scenario 1 will depend not only on queues, but on the priority of the >>> problematic project. >>> >>> Scenario 2 - yes, queues can handle dependency issues, by pipelining (as >>> Craig said) builds into a line. >>> >>> Basically you can use queues (and queue locking) to stop certain >>> combinations of projects building in parallel. E.g. If you have two >>> projects, A+B, and B includes A - you would put them both in a queue, set >>> the priority on B to be logically lower (numerically higher) than A, and off >>> you go. >>> >>> Does that help? >>> >>> >>> >>> >>> -- >>> Matt Chatterley >>> Mattched IT Ltd >>> http://www.mattchedit.com >>> UK Registered Company: 05861949 >>> >>> >>> 2009/3/11 Craig & Sammi Sutherland <[email protected]> >>> >>>> Hi Siddharth, >>>> >>>> >>>> >>>> Queues would handle both of these scenarios, but I think the main reason >>>> queues were implemented was to reduce resource contention. Putting multiple >>>> projects in a queue means only one project can access the resources at any >>>> time. >>>> >>>> >>>> >>>> They also help group related projects together into a “pipeline” type >>>> scenario, e.g. project one compiles the code, while project two tests it. >>>> You wouldn’t want project one to start compiling the code again while >>>> project two is still testing. >>>> >>>> >>>> >>>> These are just based on my understanding, as I was not the original >>>> developer. >>>> >>>> >>>> >>>> >>>> >>>> Craig >>>> >>>> >>>> >>>> *From:* [email protected] [mailto: >>>> [email protected]] *On Behalf Of *jonty s >>>> *Sent:* Wednesday, 11 March 2009 7:21 p.m. >>>> *To:* [email protected]; [email protected] >>>> *Subject:* [ccnet-devel] Build Queue Scenarios >>>> >>>> >>>> >>>> Here Im trying to understand the scenarios of build queue. >>>> >>>> Why do queue's exist in the first place ? >>>> >>>> Scenario1 : Is it because its possible for a build to start again (due >>>> to scheduling) without a earlier build completing ? >>>> >>>> Scenario2 : Queues help control the dependencies between independent >>>> builds ? Web application build is dependent on web server build completing. >>>> >>>> ??? >>>> >>>> Please give me a few pointers to understnad the problem we are tryng to >>>> solve using queues. >>>> >>>> Regards >>>> >>>> Siddharth >>>> >>> >>> >>> >>> >> >
