[
https://issues.apache.org/jira/browse/CONTINUUM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496280#comment-14496280
]
Brent N Atkinson commented on CONTINUUM-2752:
---------------------------------------------
It is worth noting that this was previously impossible for distributed builds.
Previously, build results were not created until an agent returned a result to
the master. Now, build results are created in advance of an agent build, so it
is possible to coordinate build information between master and agent using
build result id or (when this is finished) the result's build number.
> Always assign a new build number when starting a build
> ------------------------------------------------------
>
> Key: CONTINUUM-2752
> URL: https://issues.apache.org/jira/browse/CONTINUUM-2752
> Project: Continuum
> Issue Type: Improvement
> Affects Versions: 1.5.0
> Reporter: Brent N Atkinson
> Fix For: 1.5.0
>
>
> The way that build numbers are assigned is not intuitive and it adds
> unnecessary complexity to the system. By always assigning a new build number
> to new builds, it becomes a simple, intuitive and reliable identifier and
> complexity can be reduced.
> Why it is not intuitive:
> Currently, a new build number is only assigned to a build when the build
> outcome is successful. This means that a build number can not be used to
> reference an arbitrary build: in-progress or failed builds don't have a
> unique build number. While perhaps handy for conserving build numbers, this
> scheme's utility for identifying builds is dubious. As an alternative, the
> internal build id can be used to uniquely identify any build, but it is also
> not intuitive because its domain covers all build results regardless of
> project. It will appear to leap past what most people would expect to be the
> next build number for the project.
> The reason it complicates the system:
> Unsurprisingly, for the same reason it is not intuitive for humans: it is an
> unreliable way of uniquely identifying builds. Every part of the system
> dealing with build numbers has to account for the conditional nature of the
> number. This leads to branching logic wherever it is used adding complexity.
> Because the build number is unknown until a build finishes, another more
> reliable mode of identification is required. Also, it complicates build
> result handling, particularly when using distributed build agents, because
> assignment must be handled at the end of the build and the result must
> identified uniquely to correctly assign it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
