continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marica Tan <marica....@gmail.com>
Subject Re: Thoughts on build environment selection when releasing in distributed build setup
Date Wed, 03 Feb 2010 06:30:54 GMT
On Wed, Feb 3, 2010 at 10:58 AM, Jevica Arianne B. Zurbano <
jevica.arianne@gmail.com> wrote:

> 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 )
>
> This is already out of the scope for this issue :)

We can create another issue that will handle this.


> 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();
>
>
> IMHO, we could have a simple fix for now, like being able to set an
environment variable (e.g. heap size) or a build tool (jdk, maven or ant)
during release and then ignore the build agent group in the build
environment for the meantime.


Thanks,
--
Marica

>
>
> 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 <wsmoak@gmail.com> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message