[Capistrano] Have new roles NOT run for :setup

[Steve Downey]

I have added a new role (role :new_role, new_role) for some tasks 
specific to that box.

Now the :setup (and other) tasks that have no role restrictions, and so 
run for all roles, are trying to execute on the new_role box. 

What is the simplest approach to having standard tasks NOT execute for 
my new roles?

--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---

[Capistrano] How to execute remote svn command

[Steve Downey]

(I'm not after the deploy or update_code task here).

I want to have a task that will export code (not the rails app) from an
arbitrary part of the repository to an arbitrary location on the remote
host. Also, make no assumptions about logins/public keys; the windows
machine running the task, the remote unix host and the svn host all may
have different ids and passwords.

I like to be able to have a task something like:

task :an_svn_export, :roles = :web do
 run "svn export svn+ssh://some-user@svn.host.source-dir
target-dir
end
  

and have it prompt me for "some-user"'s svn password.

--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
  For more options, visit this group at http://groups.google.com/group/capistrano  -~--~~~~--~~--~--~---

[Capistrano] Public Key Access From Windows Desktop to Unix Server

[Steve Downey]

I am having problems connecting from my Windows desktop to my :web box 
(Solaris) using public key exchange.

Using SSH Secure Shell I can connect to the Unix box using public key, 
but when I run a Capistrano task it prompts me for a password.  My 
Windows account is different than my unix account, but that's the case
when connecting via SSH Secure Shell so I doubt that's the issue.

Anyone gotten this to work from Windows?

--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---

[Capistrano] and || in tasks

[Steve Downey]

This is probably more of a unix question than Capistrano.

If I have several commands to string together, I know I can to that with 
.  But what do I do if I have several steps and I want them all 
executed regardless of the success of prior commands.

An example might be a task to get my mongrel server running, regardless 
of what state it is in.  I don't want to write code to look for the pid 
file.  I'd like to do something like:

run cd {current_path}  mongrel_rails stop  mongrel_rails start -p 
999 -d

but if mongrel isn't running, stop isn't happy.  And if it is running 
start is unhappy.

--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---

[Capistrano] Re: cap and Solaris

[Steve Downey]

The solution sort-of worked for me.  The problem is the deploy dies
first time out since current_path doesn't yet exist.

I wound up adding an :after_setup that touches current_path so it
exists when deploy calls symlink.

Is there a way to get commands strung together with  to run if the
prior one fails?

On Jan 6, 9:04 am, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
 Just a heads up to anyone using cap to deploy apps on Solaris...

 I ran into problems with thesymlinktask... It would end up creating
 links to the new release inside the previous release directory (which
 prior to running a deploy was current) and the current link would
 not change.

 The only fix I could come up with is to modify thesymlinktask either
 in standard.rb at
 ${WHERE_EVER_RUBY_GEMS_LIB_IS_FOR_YOU}/capistrano-x.x.x/lib/capistrano/recipes/standard.rb
 or in a deployment recipe (config/deploy.rb)
 to remove the current link before creating it...

 task :symlink, :except = { :no_release = true } do
   on_rollback { run rm #{current_path}  ln -nfs #{previous_release}
 #{current_path} }
   run rm #{current_path}  ln -nfs #{current_release}
 #{current_path}
 end

 (I guess you could also correct the link in a after_symlink task as
 well...)

 From quick glance at standard.rb... you'll also want to make a similar

 change to the rollback_code task as it also doesn't remove the link
 before trying to recreate it.

 The root of the problem seems to be the implementation of ln on
 Solaris. It will not properly recreate links to directories when doing
 an 'ln -nfs source_dir target'. I've only been able to try this out
 on Solaris 10 (11/06) and the most recent release of OpenSolaris...

 A quick way to see this without running cap: `mkdir dir1 dir2  ln
 -nfs dir1 slink  ls -al slink  ln -nfs dir2 slink  ls -al slink
  ls -al dir1`


--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---