could not find any strategy named `checkout'

[Parker McGee]

Whenever I try to deploy using Capistrano 2.4.0, I get the following
output:

$ cap deploy
* executing `deploy'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
*** [deploy:update_code] rolling back
* executing "rm -rf /home/pmcgee/homeless-shelter/releases/
20080623053142; true"
servers: ["twistingmaze.com"]
Password:
[twistingmaze.com] executing command
command finished
could not find any strategy named `checkout'

On deploy:check, I get the same error:

$ cap -q deploy:check
could not find any strategy named `checkout'

My deploy.rb file is available here: http://pastie.org/220188

I've never had this problem before, though I did just upgrade to
2.4.0. I can't see anywhere where I'm trying to call a 'checkout'
strategy. Could someone please help? Thanks!

Parker McGee

[Jamis Buck]

Sounds like maybe you've got a botched install of capistrano. Does the
file lib/capistrano/recipes/deploy/strategy/checkout.rb exist in your
capistrano installation? What version of rubygems do you have installed?

If nothing else, you might want to "gem uninstall" all versions of
capistrano that you've got installed, and then "gem install
capistrano" and see if that works any better.

- Jamis

[nickl...@googlemail.com]

Hi,

I'm getting a similar problem with my deploy:
could not find any strategy named `remote_cache'

capistrano (2.4.0)
capistrano-ext (1.2.1)
gem 1.2.0

deploy.rb: http://pastie.org/220387
deploy/staging.rb: http://pastie.org/220389

I've tried uninstalling and reinstalling capistrano but no luck

Any ideas?
Thanks
Nick

[Jamis Buck]

Very odd. :( I can't duplicate this at all. What version of Ruby are
you using? And what OS?

- Jamis

[nickl...@googlemail.com]

I did a fresh install of Ubuntu 8.04 at the weekend

ruby 1.8.6 (2007-09-24 patchlevel 111) [i486-linux]

I wonder if it has anything to do with the new version of rubygems?

thanks
Nick

On Jun 23, 4:06 pm, Jamis Buck <ja...@37signals.com> wrote:
> Very odd. :( I can't duplicate this at all. What version of Ruby are  
> you using? And what OS?
>
> - Jamis
>

[Jamis Buck]

I don't think it is related to rubygems, since I just tried
uninstalling capistrano and reinstalling (using rubygems 1.2.0) and I
can find the remote_cache strategy just fine. What does the lib/
capistrano/recipes/deploy/strategy directory look like in your
capistrano installation? Is there a remote_cache.rb file?

- Jamis

[nickl...@googlemail.com]

nick@nick-laptop:~$ ls -l /usr/lib/ruby/gems/1.8/gems/capistrano-2.4.0/
lib/capistrano/recipes/deploy/strategy
total 32
-rw-r--r-- 1 root root 2562 2008-06-23 14:36 base.rb
-rw-r--r-- 1 root root 533 2008-06-23 14:36 checkout.rb
-rw-r--r-- 1 root root 8417 2008-06-23 14:36 copy.rb
-rw-r--r-- 1 root root 469 2008-06-23 14:36 export.rb
-rw-r--r-- 1 root root 1488 2008-06-23 14:36 remote_cache.rb
-rw-r--r-- 1 root root 1735 2008-06-23 14:36 remote.rb

I've tried uninstalling all the gems relating to capistrano but this
did not help either. I also tried running capistrano 2.3.0 (which it
was working for previously) but that did not help

Thanks
Nick

On Jun 23, 4:54 pm, Jamis Buck <ja...@37signals.com> wrote:
> I don't think it is related to rubygems, since I just tried  
> uninstalling capistrano and reinstalling (using rubygems 1.2.0) and I  
> can find the remote_cache strategy just fine. What does the lib/
> capistrano/recipes/deploy/strategy directory look like in your  
> capistrano installation? Is there a remote_cache.rb file?
>
> - Jamis
>

[Jamis Buck]

Do you have a .caprc file in your home directory? What does your
Capfile look like? Do you have any plugins in vendor/plugins that have
cap recipes?

I'm just wondering if there is something, somewhere, that is mucking
with your load path. Try adding this to the bottom of both your
deploy.rb and deploy/staging.rb files:

puts(__FILE__, load_paths.join(":"))

The load paths that are printed should be (by default) "." and the
path to the "recipes" subdirectory in your capistrano installation (/
path/to/gems/capistrano-2.4.0/lib/capistrano/recipes).

- Jamis

On Jun 23, 2008, at 10:10 AM, nick.l...@googlemail.com wrote:

>
> nick@nick-laptop:~$ ls -l /usr/lib/ruby/gems/1.8/gems/
> capistrano-2.4.0/

[nickl...@googlemail.com]

not sure this is going to help much but see below

thanks
Nick

On Jun 23, 5:21 pm, Jamis Buck <ja...@37signals.com> wrote:
> Do you have a .caprc file in your home directory?

No

> What does your  
> Capfile look like?

http://pastie.org/220451

> Do you have any plugins in vendor/plugins that have  
> cap recipes?

The only plugins installed are:
nick@nick-laptop:~/git/nyvej-accreditation (master)$ ls -l vendor/
plugins/
total 24
drwxr-xr-x 4 nick nick 4096 2008-06-21 17:07 acts_as_state_machine
drwxr-xr-x 8 nick nick 4096 2008-06-21 17:07 exception_logger
drwxr-xr-x 4 nick nick 4096 2008-06-21 17:07 manage_fixtures
drwxr-xr-x 4 nick nick 4096 2008-06-21 17:07 restful-authentication
drwxr-xr-x 13 nick nick 4096 2008-06-21 17:07 rspec
drwxr-xr-x 8 nick nick 4096 2008-06-21 17:07 rspec_on_rails

>
> I'm just wondering if there is something, somewhere, that is mucking  
> with your load path. Try adding this to the bottom of both your  
> deploy.rb and deploy/staging.rb files:
>
>    puts(__FILE__, load_paths.join(":"))
>
> The load paths that are printed should be (by default) "." and the  
> path to the "recipes" subdirectory in your capistrano installation (/
> path/to/gems/capistrano-2.4.0/lib/capistrano/recipes).

I get: http://pastie.org/220453
all the paths look correct to me

>
> - Jamis

[sean]

Hi Jamis et al,

I am running capistrano 2.4 on os x 10.5, and I have having the same
problem:

cap deploy:check
* executing `deploy:check'

could not find any strategy named `checkout'

That is after commenting out the line: set :deploy_via, :remote_cache

When that line is left in I get:
* executing `deploy:check'
could not find any strategy named `remote_cache'

I haven't had any problems with other gems, so I don't think the
problem is with my load path. cap -V returns Capistrano v2.4.0

I am having this problem both with a new rais app that uses a git
repository and my old rails apps that use subversion.

thanks in advance for any ideas,
Sean

On Jun 23, 12:33 pm, "nick.linn...@googlemail.com"

[Jamis Buck]

I'm sorry all, but I'm at a loss here. I can't duplicate it (using OS
X 10.5, Ruby 1.6, Cap 2.4, gems 1.2, etc.). If you are having this
problem, I'm afraid I'm going to have to call on you to dig into the
code and see what's going on. That, or help me to duplicate the
problem so I can investigate. :(

- Jamis

[Jamie Orchard-Hays]

I just tried it on three apps and all work fine (also using
RailsMachine).

Leopard 10.5.3, Cap 2.4, gem 1.1.1, ruby 1.8.6 (2007-09-24 patchlevel
111) [universal-darwin9.0]

Jamie

[sean]

Hi Jamis,

Well, I really wouldn't know where to begin in terms of digging
through the code. One thing I noticed, though (not sure if this is
relevant) is that on my system, there is a symbolic link at /usr/lib/
ruby which points to /System/Library/Frameworks/Ruby.framework/
Versions/Current/usr/lib/ruby
in which I find a gems directory which has some gems, but not the
capistrano gem. Additionally there is a gems directory in the path /
usr/local/lib/ruby/gems/1.8/gems which has the capistrano and other up
to date gems. I wonder if some part of capistrano is using the wrong
gem path?

Take care,
Sean

[Jamis Buck]

Is there a /usr/local/bin/ruby? Is /usr/local/bin ahead of /usr/bin in
your path? What happens if you remove the /usr/bin/ruby symlink?

- Jamis

[sean]

Thanks, I will try all of that just as soon as I can install
capistrano... I think maybe the rubygems server is down or
something... I am getting:
sudo gem install capistrano
Bulk updating Gem source index for: http://gems.rubyforge.org/
ERROR: could not find capistrano locally or in a repository

[sean]

Hi Jamis,

Now running gems 1.2 and Capistrano 2.4 again. My path output is
-bash: /usr/local/git/bin:/usr/local/bin:/usr/local/sbin:/usr/local/
bin:/usr/local/mysql/bin:/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/
usr/local/bin:/usr/X11/bin:/opt/local/bin:/usr/local/git/bin: No such
file or directory

Yes, there is a /usr/local/bin/ruby and nothing has changed after
removing the /usr/bin/ruby symlink...

- Sean

[Peter Booth]

I appreciate that the subject header of this question sounds nonsensical, but it is a genuine question and I would be grateful for any suggestions...

Our situation:

we have two "instances" of the same Rails application and are deploying both to our production, stage, loadtest, uat and other stages.

There are some small code differences between the two instances, that is managed in subversion as two branches. The medium term plan

 is to abstract this differing functionality out and have a single Rails application.

In our current model we use the Capistrano :application variable to denote the application instance.

How can we have configuring this :application variable dynamically within our deploy.rb script?

Peter Booth

[Parker McGee]

Well, I just tried to run it sudo'd and `cap deploy:check` worked just
fine, so it seems like it may be a permissions problem, but I have
read permissions for other set on all the gem files, and I can cat the
files just fine, so that's obviously not the problem. Any other
thoughts?

Parker McGee

[nickl...@googlemail.com]

I've not had time to dig further into it but commenting out the rescue
in recipes/deploy/strategy.rb gives this:

/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:32:in
`gem_original_require': no such file to load -- capistrano/recipes/
deploy/local_dependency (LoadError)
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:32:in
`require'
from /usr/lib/ruby/gems/1.8/gems/capistrano-2.4.0/lib/capistrano/
recipes/deploy/dependencies.rb:1
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require'
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
from /usr/lib/ruby/gems/1.8/gems/capistrano-2.4.0/lib/capistrano/
recipes/deploy/strategy/base.rb:1
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require'
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
from /usr/lib/ruby/gems/1.8/gems/capistrano-2.4.0/lib/capistrano/
recipes/deploy/strategy/remote.rb:1
... 28 levels...
from /usr/lib/ruby/gems/1.8/gems/capistrano-2.4.0/lib/capistrano/cli/
execute.rb:14:in `execute'
from /usr/lib/ruby/gems/1.8/gems/capistrano-2.4.0/bin/cap:4
from /usr/bin/cap:19:in `load'
from /usr/bin/cap:19

Does this help at all?

local_dependency.rb does exists

Thanks
Nick

[Parker McGee]

I'm not sure what the over-arching reason for this is, but I realized
that some random rubygem files aren't getting read-access for others.
For example, capistrano/recipes/deploy/local_dependency.rb didn't have
read permissions. This happened on other gems as well. I actually
figured this out because sqlite-ruby wasn't getting loaded correctly
due to a file not having read permissions.

So, I ended up fixing this by running `sudo chmod -R +r capistrano` in
the capistrano gem's lib directory.

I'm not sure if this is an 'acceptable' fix. I would love to know
exactly what the problem is here.

Parker McGee

On Jun 24, 5:34 am, "nick.linn...@googlemail.com"

> ...
>
> read more »

[Jamis Buck]

That...seems really odd. I have no idea how that could happen. It does
explain why running as root works, though. Good find, Parker. Thanks
for keeping us in the loop.

- Jamis

[benr75]

I can confirm this same issue, getting the error: could not find any
strategy named `checkout'. All my deploys stopped working unless
called via sudo. I am on:

Mac OS X 10.5.3
Gem 1.2.0
Capistrano v2.4.0

Tricky to figure out which operation created the botched permissions.

~ Ben

> ...
>
> read more »

[Jamis Buck]

When you installed capistrano, did you do "gem install" as your user,
or as root? And, did you install with gem 1.2, or a different version?
Also, which Ruby are you using--the default ruby that ships with Mac
OS X, or the macports version, or a custom install?

- Jamis

[Jamis Buck]

Alright, I think we've figured this out. Parker's tip about the
permissions on local_dependency.rb led me to investigate my own
capistrano install, and sure enough, the file in question was user and
group readable, but not world readable. However, since my user is in
the same group as the file in question, I didn't have any problem.

Digging deeper, I found that the local_dependency.rb file in my local
capistrano repository had the same permissions issue. Some poking
around with 'git ls-tree' didn't indicate that the file itself had
ever been committed with those permissions, so I resorted to brute
force and nuked my local capistrano repository, and cloned it again
from github. And the perms were correct on that file now.

So, I suspect that rubygems kept the bad permissions when I built the
2.4.0 gem, and made sure the permissions were preserved on each
install. Until a new gem is available, fixing the permissions on the
lib/capistrano/recipes/deploy/local_dependency.rb file should fix any
problems you have. I'll try to get 2.4.1 out this week.

Thanks for everyone who contributed to this investigation. I apologize
for the frustration!

- Jamis

[nickl...@googlemail.com]

Confirmed, same problem here in Linux land.

I did a chmod 0755 on my capistrano gem directory and I can deploy
fine now.

Many thanks Parker and Jamis

Nick

> ...
>
> read more »

[Jonathan Weiss]

Jamis Buck wrote:
> So, I suspect that rubygems kept the bad permissions when I built the
> 2.4.0 gem, and made sure the permissions were preserved on each
> install. Until a new gem is available, fixing the permissions on the
> lib/capistrano/recipes/deploy/local_dependency.rb file should fix any
> problems you have. I'll try to get 2.4.1 out this week.

Today we debugged a similar permission issue with sqlite3 on a
colleagues computer.

Jonathan

--
Jonathan Weiss
http://blog.innerewut.de
http://twitter.com/jweiss

[Jamis Buck]

What file were the bad permissions on? I'm not seeing any bad perms on
my own sqlite3-ruby install, so I don't think it's the fault of the
gem this time.

- Jamis

[David Masover]

I haven't noticed any bad permissions on installed gems at all, yet.

[Jonathan Weiss]

Jamis Buck wrote:
> What file were the bad permissions on? I'm not seeing any bad perms on
> my own sqlite3-ruby install, so I don't think it's the fault of the
> gem this time.

Both lib/sqlite3/database.rb and lib/sqlite3/translator.rb had no global
read permissions. I'm not sure which version of sqlite3 it was, I'll
have to check with my colleague.

[Jamis Buck]

Yup, those had bad perms in my local repo, but not in my sqlite3-ruby
installation. Strange! I've fixed my perms locally, and I'll add
sqlite3-ruby as another package that ought to be gemmed-up this week.

- Jamis