Re: In distributed build, how does Continuum decide whether there have been scm changes?

[Marica Tan <ct...@exist.com>]

On Tue, Jan 27, 2009 at 8:46 AM, Brett Porter <br...@apache.org> wrote:

>
> On 26/01/2009, at 5:43 AM, Marica Tan wrote:
>
>  So here's my problem. As you can see from the scenario above, when it
>> tried
>> to build from agent 2 at 2:00, it checked out the project at r101 with no
>> scm changes.
>> How can it get the changes from r100 to r101? This also happens at 3:00.
>> It
>> only gets the scm changes from r101 to r102. It can only have the scm
>> changes from r100 to r102 if it build on agent 1 again just like at 3:30
>> (merging of scm results will happen).
>>
>> Do you know how to solve this? Any suggestions?
>>
>
> One of the reasons I initially thought it'd be good to attach the agent to
> use to a build definition was that it meant that it wouldn't matter - the
> checkout on the agent could be used to determine (because we actually want
> to separate the update checks per build definition).
>
>
>>
>>
>> Here's also a solution on what Wendy wants: (though i'm not that familiar
>> with version controls, just know how to use one, so I don't know if this
>> will work)
>>
>> 1.) agent updates checkout
>> 2.) return result with revision number?
>> 3.) master checks if up to date and perform other checks to determine
>> whether agent should build the project or not. scm result may need an
>> additional field like "Revision Number"
>> 4.) master then decides whether to let the agent build or not based on #3
>>
>>
>> Is it possible to get the revision number when we do an update in
>> continuum?
>>
>
> Yep, but something to bear in mind is that not all systems support an
> atomic revision number (eg, CVS). Perhaps the date could be used in its
> stead here - as long as it's used consistently (with no gaps in time) it
> should be fine (though date is bad to use in subversion, since it doesn't
> always work).
>
> I was actually thinking we should create a separate record from the
> checkout about what the last build was anyway (as this would support the
> multiple build definitions as well). This might be a good opportunity.
>
>
How do you get the last commit date in Maven SCM?

Re: In distributed build, how does Continuum decide whether there have been scm changes?

[Marica Tan <ct...@exist.com>]

In my recent commit, I added a check that will compare the last commit date
of the previous build with the last commit date of the current build to know
whether the project should be build or not. This works if the agent already
has a working copy and if the provider supports changelog since the agent
will call the update command which will return an UpdateScmResult which
contains changes that has a date.

If it's the first time that an agent will build the project, it will execute
a checkout command which will return a CheckoutScmResult but no commit dates
on that result. I think I can still get the last commit date by using the
ChangeLog command but not all providers support that.


Thanks
--
Marica

On Mon, Feb 16, 2009 at 11:13 AM, Marica Tan <ct...@exist.com> wrote:

>
>
> On Tue, Jan 27, 2009 at 8:46 AM, Brett Porter <br...@apache.org> wrote:
>
>>
>> On 26/01/2009, at 5:43 AM, Marica Tan wrote:
>>
>>  So here's my problem. As you can see from the scenario above, when it
>>> tried
>>> to build from agent 2 at 2:00, it checked out the project at r101 with no
>>> scm changes.
>>> How can it get the changes from r100 to r101? This also happens at 3:00.
>>> It
>>> only gets the scm changes from r101 to r102. It can only have the scm
>>> changes from r100 to r102 if it build on agent 1 again just like at 3:30
>>> (merging of scm results will happen).
>>>
>>> Do you know how to solve this? Any suggestions?
>>>
>>
>> One of the reasons I initially thought it'd be good to attach the agent to
>> use to a build definition was that it meant that it wouldn't matter - the
>> checkout on the agent could be used to determine (because we actually want
>> to separate the update checks per build definition).
>>
>>
>>>
>>>
>>> Here's also a solution on what Wendy wants: (though i'm not that familiar
>>> with version controls, just know how to use one, so I don't know if this
>>> will work)
>>>
>>> 1.) agent updates checkout
>>> 2.) return result with revision number?
>>> 3.) master checks if up to date and perform other checks to determine
>>> whether agent should build the project or not. scm result may need an
>>> additional field like "Revision Number"
>>> 4.) master then decides whether to let the agent build or not based on #3
>>>
>>>
>>> Is it possible to get the revision number when we do an update in
>>> continuum?
>>>
>>
>> Yep, but something to bear in mind is that not all systems support an
>> atomic revision number (eg, CVS). Perhaps the date could be used in its
>> stead here - as long as it's used consistently (with no gaps in time) it
>> should be fine (though date is bad to use in subversion, since it doesn't
>> always work).
>>
>> I was actually thinking we should create a separate record from the
>> checkout about what the last build was anyway (as this would support the
>> multiple build definitions as well). This might be a good opportunity.
>>
>>
> How do you get the last commit date in Maven SCM?
>