Hi
I think your missing something here, or maybe I am ;-)
those settings only control the queues, so which projects get build.
--> this has nothing to do with the actual changes in the source control
when A2 is about to be build by CCNet, but the dev that made A3 appear in
the Q, committed his code
meaning that when CCNet is running the 'A2', it will get the changes from A2
AND A3
it is doing getmodifications, so it will get all modifications unitill the
current date (which is now)
not 100% about this, but 99.9%
maybe check which timestamps (if any) are passed to the source control
get allmods between :
° time last integration and now
or
° time last integration and timestamp of when project was added to the queue
with kind regards
Ruben Willems
On Thu, Mar 26, 2009 at 7:54 AM, jonty s <[email protected]> wrote:
> 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
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
