continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Thoughts on build environment selection when releasing in distributed build setup
Date Mon, 15 Feb 2010 04:20:54 GMT
Thanks for writing this up, it's quite helpful. I'll pick a few things from the thread.

On 13/02/2010, at 2:38 AM, Jevica Arianne B. Zurbano wrote:

> Updated wiki for CONTINUUM-2386 (Build environment selection is ignored when releasing
with distributed build enabled)
> http://cwiki.apache.org/confluence/display/CONTINUUM/Build+Environment+Selection+During+Release
> 
> These are the issues to be fixed/implemented: (under the References section from the
link above)
> <http://jira.codehaus.org/browse/CONTINUUM-2386>CONTINUUM-2368 - Build environment
selection is ignored when releasing with distributed build enabled
> <http://jira.codehaus.org/browse/CONTINUUM-2458>CONTINUUM-2458 - Continuum Release
should do a checkout if there is no working copy
> CONTINUUM-2464 - Build environment should be required when releasing in distributed build
setup

This looks fine to me, but it's probably trying to tackle too much at once, and as Wendy said
we might want to do a greater review of dist. builds and interactions with these bits. This
would be good input for that.

I would focus on making it behave consistently in the short term, with simple rules. So it
sounds like, from my reading of the thread:
- require a build environment for release in dist. builds
- use same rules to select agent as any other build would
- if no checkout exists, do one (which I assume any other build would do too)

is that right?

One other point:

On 03/02/2010, at 1:04 PM, Wendy Smoak wrote:

> There's no relationship between a successful build in the past and a
> successful release now.  A commit in between could have fixed (or
> broken) the build, giving a different result when you try to release.
> 
> This feels like an arbitrary restriction that could be removed.

It was intended to do the release from the revision that was last successfully built - but
we're finding more and more that releases are always done from the latest revision, so you're
right and the restriction has become arbitrary, and it means having 3 builds to push a release,
which is over the top!

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





Mime
View raw message