From what I have investigated, the current behavior is that it only updates the working copy (UpdateWorkingCopyPhase.java code snippet below) that is why the working copy is needed and attempting to release it on another build agent might fail if the working copy is not found. IMO, the checking out of the working copy could be applied in this case.

   try
   {
result = provider.update( repository, new ScmFileSet( new File( releaseDescriptor.getWorkingDirectory() ) ), (ScmVersion) null );
   }
   catch ( ScmException e )

The build agent to be used is determined or taken from the last project build result (DefaultDistributedReleaseManager.java code snippet below). This is why it always result to using the last or default build agent. However, it is possible to set it to use the build agent from the selected environment.

BuildResult buildResult = buildResultDao.getLatestBuildResultForProject( project.getId() );
   String buildAgentUrl = buildResult.getBuildUrl();



Marica Tan wrote:
I think the reasons why it needs to have a previous successful build are:

1. to make sure there is a working copy
2. to make sure we have a successful build before we tag. there is no sense
to release a project if the build failed because the release will fail as
well.


Thanks,
-
Marica

On Wed, Feb 3, 2010 at 9:14 AM, Wendy Smoak <[email protected]> wrote:

I had a long conversation with myself about this on the drive home,
and I keep going in circles.  I don't know how much of the existing
behavior is intentional vs. incidental.

In non-distributed build, it will not let you do a release unless the
projects are in 'build success' state. Obviously, the release happens
on that working copy.

Carrying that over to distributed build, you still have to have a
previous successful build.  IF the release has to happen on that
working copy, then you don't get to pick the build agent.  And since
the build agent is part of the build environment...

So, can someone explain why you have to have a previous successful
build in order to do a release?  It's not a requirement at the maven
command line.  The release might fail, but you are not prevented from
trying it.

Is this a real requirement, or can we go with Brett's idea that
Continuum Release should do a checkout, which would mean it could
happen anywhere?

+1 on doing a checkout
I am not sure if this is a requirement though.

Honestly I think this work should be delayed until the architecture
changes are sorted out.  It shouldn't be this complicated.
--
Wendy



--

Thanks,

Jev

Reply via email to