From: Steven Hansen <runner@...>
Date: 2006-12-01T08:10:04+09:00
Subject: Re: Capistrano Connection Caching Question

Ezra Zygmuntowicz wrote:
>
> On Nov 30, 2006, at 7:41 AM, Steven Hansen wrote:
>
>> Hi,
>>
>> I'm trying to clear up my understanding of how some of the Capistrano 
>> connection stuff works. In the Capistrano manual, I found the following
>>
>> "All |run| does is attempt to execute the given command on all 
>> associated remote hosts. (We�ll talk more later about the available 
>> helper methods, of which |run| is the most commonly used.) This means 
>> that as soon as run is invoked, Capistrano inspects the current task 
>> and determines what roles are active, and then determines which 
>> servers those roles map to. If no connection has been made a server 
>> yet, the connection is established and cached, and then the command 
>> is executed in parallel. /This means that no connections are made to 
>> the remote hosts until they are actually needed."/
>>
>> I'm a bit confused about what it means to "cache" the connection. 
>> Let's say I have the following tasks:
>>
>> ---------------------------------------------------------------------
>> task :wrapper do
>> show_env
>> set_gem_home
>> show_env
>> end
>>
>> task :show_env do
>> run 'env'
>> end
>>
>> task :set_gem_home do
>> run 'export GEM_HOME=/path/to/ruby/gems'
>> end
>> ----------------------------------------------------------------------
>>
>> What I'm seeing--when I run the :wrapper task--is that on the second 
>> call to :show_env GEM_HOME is not set on the remote machine's 
>> environment. If the connection is being cached, after the first call 
>> to :set_gem_home wouldn't GEM_HOME be set for all subsequent tasks 
>> for that machine?
>>
>> I realize that the easiest way to set something like GEM_HOME is to 
>> configure it in a .ssh/environment file. However, our sys admins have 
>> disabled the [PermitUserEnvironment] option in the sshd_config file. 
>> As things stand right now, I have to prepend all commands like this 
>> [export GEM_HOME=/path/to/ruby/gems && gem install super_gem]. I'd 
>> like to avoid this if possible.
>>
>> Regards,
>> Steven
>
>
> Hey Steven-
>
>     What you need to know is that calls to run are all new calls. So 
> if you export a env variable in one call to run and then try to use it 
> in another call to run it will not be there. Same thing if you cd into 
> a directory in one call to run and then try to do something in that 
> dir with another call to run. The way around this is to call run will 
> a series of commands in the same run call:
>
> run "export GEM_HOME=/path/to/ruby/gems &&
>          ln -s whatever foo &&
>          cd /some/path &&
>          touch whatever"
>
>     So the idea is that if commands you call depends on something set 
> in a previous call to run you need to rework them into a chained 
> command like above.
>
> Cheers-
> -- Ezra Zygmuntowicz-- Lead Rails Evangelist
> -- ez@engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
>

Cool,
Thanks!