You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@continuum.apache.org by "Brent N Atkinson (JIRA)" <ji...@apache.org> on 2015/05/13 03:54:00 UTC

[jira] [Closed] (CONTINUUM-2767) Agent builds duplicate last change in prior result as first in subsequent result

     [ https://issues.apache.org/jira/browse/CONTINUUM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brent N Atkinson closed CONTINUUM-2767.
---------------------------------------
    Resolution: Pending Closed

Fixed in r1679125.

> Agent builds duplicate last change in prior result as first in subsequent result
> --------------------------------------------------------------------------------
>
>                 Key: CONTINUUM-2767
>                 URL: https://issues.apache.org/jira/browse/CONTINUUM-2767
>             Project: Continuum
>          Issue Type: Bug
>    Affects Versions: 1.4.2
>            Reporter: Brent N Atkinson
>            Assignee: Brent N Atkinson
>             Fix For: 1.5.0
>
>
> There is an inconsistency with the way SCM changes are computed for master-only builds and master-agent builds. Master-only builds include the changelog for all changes since the start of the prior build. Master-agent builds include the changelog since the lastChangedDate of the prior build. This results in inconsistent changes between the two modes, with agent builds duplicating changes between builds.
> In the short-term, the methods should at least be made consistent with each other. However, it is worth noting that neither of these is strictly correct. Because the method uses the time to compute the changes, differences in time between master and agent will have a noticeable effect on the changeset. Also, changes can be duplicated or omitted based on overlapping or gaps in the times between builds. It would be better to use revision ranges to do this, but this will likely require changes to the scm subsystem to support.
> To reproduce the problem, simply create a sample project and a script that commits changes with a unique message (I used a sequential number to make it easy to identify overlap). Shorten the schedule so that you can get quick builds and compare the prior and subsequent result pairs. You should see that the last change in the prior build is also included as the first change in the subsequent result.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)