From: Ezra Zygmuntowicz <ezmobius@...>
Date: 2006-12-01T06:28:12+09:00
Subject: Re: Capistrano Connection Caching Question


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)