capistrano / capistrano Goto Github PK
View Code? Open in Web Editor NEWA deployment automation tool built on Ruby, Rake, and SSH.
Home Page: http://www.capistranorb.com
License: MIT License
A deployment automation tool built on Ruby, Rake, and SSH.
Home Page: http://www.capistranorb.com
License: MIT License
Every released version of Capistrano starting with 2.5.21 declares it was released March 21, 2011. Incorrect past dates makes the project look stagnant. :(
Hi there,
I'm writing a build script for my node.js application. The node.js instance is governed with forever. From SSH, if I run:
cd /opt/app/current/src && forever start app.js
then run
forever list
I get
[root@symbleBackend src]# forever list
info: Running action: list
info: Forever processes running
data: uid command script forever pid logfile uptime
data: [0] 08Me node app.js 23287 23288 /root/.forever/08Me.log 0:0:0:5.415
However, if I use capistrano, the following happens:
puts capture "cd #{deploy_to}/current/src/ && forever start #{node_file}"
then run (from a separate task)
puts capture "forever list"
I get
[root@symbleBackend src]# forever list
info: Running action: list
info: No forever processes running
I'm running Capistrano and SSH from the same machine, as the same user, with the same private key.
What reason could there be for this? Surely Capistrano just opens an SSH connection and runs the commands? If so, what difference is there between me using SSH manually and me piping it through Capistrano.
hey, I am able to successfully with cap deploy form Mac, however, when I do it from Linux, I get "ArgumentError: invalid byte sequence in US-ASCII" error. I tried to play around with LANG variable, but it doesn't seem to help
export LANG=""
$ cap staging deploy
* executing staging' * executing
deploy'
* executing deploy:update' ** transaction: start * executing
deploy:update_code'
triggering before callbacks for deploy:update_code' * executing
install_bundler'
* executing "if [ -z which bundle
]; then echo 'no bundler!' && gem install bundler; fi"
servers: ["xxxx.com"]
connection failed for: xxxx.com (ArgumentError: invalid byte sequence in US-ASCII)
export LANG="en_US.UTF-8"
$ cap staging deploy
deploy:update_code' triggering before callbacks for
deploy:update_code'which bundle
]; then echo 'no bundler!' && gem install bundler; fi"05c707c breaks compatibility with git 1.6. Git 1.6.3.3 is still the latest version available in Ubuntu 9.10 (less than a year old). If adding --init important or very helpful, we should think about keeping it, but otherwise I think we ought to support git 1.6.
What was the reason --init was added here? I couldn't find the mailing list discussion that @leehambley was referring to in the commit comments.
The following entry appears in CHANGELOG under 2.5.0 / August 28, 2008:
Sort releases via "ls -xt" instead of "ls -x" to allow for custom release names [Yan Pritzker]
I don't know if that change was made then reverted or what, but "ls -x" is definitely being used, which does not work with non-timestamp subdirectory names (for example the "current_release" variable can be misset, leading to all sorts of mayhem).
Either that changelog entry should be removed and the official documentation should be updated to note this assumption to avoid confusion, or the change it refers to should be made in lib/capistrano/recipes/deploy.rb line 58.
Some scm commands can accepts options that others can't.
For example, subversion export, checkout and update commands accept --ignore-externals
option, but info command does not. So using :scm_arguments
variable is impossible.
It is pretty easy to add argument variable to each command in form of: :scm_arguments_<command_name>
I have already implemented this for subversion scm on my fork of capistrano, and it seems to work pretty well. I'll make pull request soon.
The way :git_submodules_recursive is retrieved, we can't get it to disable with false.
The issue is with how SCM::Base implements variable
:
def variable(name, default = nil)
if local? && configuration.exists?("local_#{name}".to_sym)
return configuration["local_#{name}".to_sym] || default
else
configuration[name] || default
end
end
Anything explicitly set to false will cause the OR conditional to return the default, which in the case of :git_submodules_recursive is nil.
We're happy to work up a patch, but want to get some feedback if there's a preferred way to approach this.
Hi,
I have an issue that doesn't occur at all on my mac, but does on my ubuntu server. Both use the exact same Capfile and config/deploy.rb, copied over with scp.
I even set up my .ssh/config file and when I read it using NetSSH gem, it all gets read correctly.
Yet on the ubuntu machine, Capistrano will only use the key in .ssh/id_rsa, not matter what that is. When I rename my github key to id_rsa, Cap will connect to github, but not to my production server. When I rename my production key to id_rsa, it'll not be able to authenticate at github, but does get access to the production server.
I'm using the exact same configs, keys work outside of Capistrano - it's only that Capistrano stubbornly refuses to use anything but the id_rsa.
I have this in my deploy.rb:
set :ssh_options, {:forward_agent => true,
:keys => [
File.join(ENV["HOME"], ".ssh", "production.pem"),
File.join(ENV["HOME"], ".ssh", "id_rsa")
]
}
I am experimenting with a rails 3.1 app on jruby 1.6.2 and Capistrano 2.6.0
If I have capistrano commented out in the gemfile I can do things like Rake -T as follows:
$ rake -T
JRuby limited openssl loaded. http://jruby.org/openssl
gem install jruby-openssl for full support.
rake about # List versions of all Rails f...
*snip*
As you can see there is a warning about jruby-openssl even though it is installed. Annoying but not a huge problem right now. However if I uncomment Capistrano in the Gemfile and run the same command I get the following:
rake -T --trace
JRuby limited openssl loaded. http://jruby.org/openssl
gem install jruby-openssl for full support.
rake aborted!
OpenSSL::BN requires the jruby-openssl gem
Full trace in following Gist: https://gist.github.com/998544
I am assuming there is a JRuby problem here somewhere but because Capistrano causes the rake task to bomb out I thought I should mention it here in case Capistrano is doing something weird.
https://github.com/capistrano/capistrano/wiki/2.x-Multistage-Extension
The multistage extension still does not exist in lib/capistrano/ext.
Refering to: #35 and https://github.com/carlhuda/bundler/blob/1-0-stable/lib/bundler/capistrano.rb
When the Gemfile has been updated the rake task to precompile the assets will fail because bundle:install has not been run yet. I suggest to change after 'deploy:update_code', 'deploy:assets:precompile'
to before "deploy:symlink", "deploy:assets:precompile"
.
When coming to the wiki for the first time, it is not possible to understand what capistrano is and if I should care.
I found out about this project as github is featuring it in its help section. Following the link I get to the wiki but nothing explains in a simple paragraph what this project is and if it is interesting to me.
Please add a describing "about" paragraph at the top with stats what capistrano is, what it is not, what I can do with it and in which situations I should care about it.
I'm trying to use Capistrano + RVM + Bundler to manage multiple ruby versions running on the server.
At this moment, when I tried to run cap bundle:install
I got this error:
$ cap bundle:install * executing `bundle:install' * executing "ls -x /home/deploy/www/nhacker/releases" servers: ["vixplace.com"] [vixplace.com] executing command command finished in 2640ms * executing "cd /home/deploy/www/nhacker/releases/20110719194329 && bundle install --gemfile /home/deploy/www/nhacker/releases/20110719194329/Gemfile --path /home/deploy/www/nhacker/shared/bundle --deployment --quiet --without development test" servers: ["vixplace.com"] [vixplace.com] executing command ** [out :: vixplace.com] /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:1912:in `gsub': invalid byte sequence in US-ASCII (ArgumentError) ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:1912:in `to_yaml' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:79:in `block (2 levels) in write_package' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:73:in `block (3 levels) in add_gem_contents' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:83:in `new' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:67:in `block (2 levels) in add_gem_contents' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in `wrap' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in `block in add_gem_contents' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:113:in `add_file' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:63:in `add_gem_contents' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:31:in `open' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package.rb:44:in `open' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:78:in `block in write_package' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/open-uri.rb:35:in `open' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/open-uri.rb:35:in `open' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:77:in `write_package' ** [out :: vixplace.com] from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:39:in `build' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/source.rb:450:in `block in generate_bin' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/source.rb:450:in `chdir' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/source.rb:450:in `generate_bin' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/source.rb:559:in `install' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/installer.rb:58:in `block (2 levels) in run' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/rubygems_integration.rb:93:in `with_build_args' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/installer.rb:57:in `block in run' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/spec_set.rb:12:in `block in each' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/spec_set.rb:12:in `each' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/spec_set.rb:12:in `each' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/installer.rb:49:in `run' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/installer.rb:8:in `install' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/cli.rb:222:in `install' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/vendor/thor/task.rb:22:in `run' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/vendor/thor.rb:246:in `dispatch' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/vendor/thor/base.rb:389:in `start ** [out :: vixplace.com] ' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/bin/bundle:13:in `' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/bin/bundle:19:in `load' ** [out :: vixplace.com] from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/bin/bundle:19:in `' command finished in 3341ms failed: "rvm_path=$HOME/.rvm/ $HOME/.rvm/bin/rvm-shell '1.9.2-p290@faminto' -c 'cd /home/deploy/www/nhacker/releases/20110719194329 && bundle install --gemfile /home/deploy/www/nhacker/releases/20110719194329/Gemfile --path /home/deploy/www/nhacker/shared/bundle --deployment --quiet --without development test'" on vixplace.com
But when I run this command from the remote machine I got no error.
Then, after some investigation, I found out that the problem could be the $LANG var and made some tests (listed below).
How can I get the $LANG
to work inside Capistrano tasks? Thank you!
$LANG
varCOMMAND="echo \|\$LANG\|" cap invoke
returned
* executing `invoke' * executing "echo \\|$LANG\\|" servers: ["vixplace.com"] [vixplace.com] executing command ** [out :: vixplace.com] || command finished in 1067ms
But
COMMAND="echo \|\$PATH\|" cap invoke
returned the $PATH
value
$LANG
var emptyexport LANG="" rvm_path=$HOME/.rvm/ $HOME/.rvm/bin/rvm-shell '1.9.2-p290@faminto' -c 'cd /home/deploy/www/nhacker/releases/20110719194329 && bundle install --gemfile /home/deploy/www/nhacker/releases/20110719194329/Gemfile --path /home/deploy/www/nhacker/shared/bundle --deployment --without development test'
Returned:
[...] Using rails_admin (0.0.1) from git://github.com/sferik/rails_admin.git (at master) /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:1912:in `gsub': invalid byte sequence in US-ASCII (ArgumentError) from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:1912:in `to_yaml' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:79:in `block (2 levels) in write_package' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:73:in `block (3 levels) in add_gem_contents' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:83:in `new' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:67:in `block (2 levels) in add_gem_contents' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in `wrap' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in `block in add_gem_contents' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:113:in `add_file' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:63:in `add_gem_contents' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:31:in `open' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package.rb:44:in `open' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:78:in `block in write_package' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/open-uri.rb:35:in `open' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/open-uri.rb:35:in `open' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:77:in `write_package' from /home/deploy/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:39:in `build' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/source.rb:450:in `block in generate_bin' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/source.rb:450:in `chdir' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/source.rb:450:in `generate_bin' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/source.rb:559:in `install' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/installer.rb:58:in `block (2 levels) in run' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/rubygems_integration.rb:93:in `with_build_args' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/installer.rb:57:in `block in run' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/spec_set.rb:12:in `block in each' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/spec_set.rb:12:in `each' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/spec_set.rb:12:in `each' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/installer.rb:49:in `run' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/installer.rb:8:in `install' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/cli.rb:222:in `install' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/vendor/thor/task.rb:22:in `run' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/vendor/thor.rb:246:in `dispatch' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/lib/bundler/vendor/thor/base.rb:389:in `start' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/gems/bundler-1.0.15/bin/bundle:13:in `' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/bin/bundle:19:in `load' from /home/deploy/.rvm/gems/ruby-1.9.2-p290@faminto/bin/bundle:19:in `'
Is there staging support in Capistrano now?
I found some 'recipes' on the internet for this but support for it seems limited and specific to certain Capistrano and Rails versions. Based on that I decided to try to not set up something that will support staging but use the poor man's staging support by changing the deploy.rb manually each time.
But what is recommended? Is there currently a better way to do this. One that is supported by Capistrano?
This is probably an edge-case scenario as I haven't had any problems with Capistrano and the cached-copy directory using SVN as the source control, but I came across this error today when trying to deploy from a private github repo:
fatal: Not a git repository (or any of the parent directories): .git
So after some searching and debugging I was able to successfully checkout the repo to the remote server by adjusting my Capfile and specifying the name of the directory to create or use via the :
repository_cache` variable to be
set :repository_cache, "cached_copy"
I tested it a few times using underscores and hyphens and every time I used a hyphen in the name it would fail to do a checkout. Has anybody had issues with this?
This may be my misunderstanding of what exactly the workflow should be for a multi-server deployment but it seems to me that if I have a DB server, I shouldn't have to deploy code to it unless it also acts as my application server.
Running cap deploy:migrate
looks for the DB servers and runs the equivalent of rake db:migrate
on them. This one command requires many things including:
Just in order for Rails to start up and run the task.
My DB server should be concerned with only one thing: executing SQL. It's the application server's job to tell the DB server what it needs to do. And (in my opinion) it shouldn't care if it's getting a request from a Ruby app, a .NET app or anything else.
PS: This goes for the web server as well.
When deploying a project with submodules with a recent copy of Capistrano I got an error in this line:
git submodule -q update --init --recursive
saying:
Usage: /usr/bin/git-submodule [--quiet] [--cached] [add <repo> [-b branch]|status|init|update [-i|--init]|summary [-n|--summary-limit <n>] [<commit>]] [--] [<path>...]
Apparently --recursive was added in a more recent version git. I'm running 1.5.6.5 (server running Debian Sarge).
Just letting you know. Feel free to ignore this if you won't support that old version of git.
Hi,
I've recently upgraded to 2.9.0 from a modified 2.6.0 version and I'm hitting an issue on deploy:migrations. I've included the exception stacktrace at the end, but basically the command instead of inserting the text "rake" is trying to make a call to a rake method:
run "cd #{directory} && #{rake} RAILS_ENV=#{rails_env} #{migrate_env} db:migrate"
This seems due to commit f68fcae removing the fetch for rake and rails_env. It did add in a _cset of those vars, but I'm not certain what that is supposed to do and it doesn't appear to be making them available as instance vars, and so the command line is failing. I'm guessing that rails_env is would fail as well with an undefined error if the rake issue was fixed.
I'm having a hard time believing that this is an issue for everyone because it would stop people pretty quickly so I'm guessing it something particular to my setup. If anyone is experiencing this or has ideas for a fix please let me know. I'm running on Ubuntu 10.04, ruby 1.8.7-p334, rails 2.3.14 if any of that makes a difference.
Thanks,
\Peter
Stacktrace:
capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:186:in `rake': wrong number of arguments (0 for 1) (ArgumentError) from capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:186:in `send' from capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:186:in `method_missing' from capistrano-2.9.0/lib/capistrano/recipes/deploy.rb:387:in `load' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:139:in `instance_eval' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly_without_callbacks' from capistrano-2.9.0/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:89:in `execute_task' from capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:186:in `send' from capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:186:in `method_missing' from capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:104:in `migrate' from capistrano-2.9.0/lib/capistrano/recipes/deploy.rb:400:in `load' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:139:in `instance_eval' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly_without_callbacks' from capistrano-2.9.0/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:89:in `execute_task' from capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:186:in `send' from capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:186:in `method_missing' from capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:104:in `migrations' from ./config/deploy.rb:69:in `load' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:139:in `instance_eval' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly_without_callbacks' from capistrano-2.9.0/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:89:in `execute_task' from capistrano-2.9.0/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task' from capistrano-2.9.0/lib/capistrano/cli/execute.rb:46:in `execute_requested_actions_without_help' from capistrano-2.9.0/lib/capistrano/cli/execute.rb:45:in `each' from capistrano-2.9.0/lib/capistrano/cli/execute.rb:45:in `execute_requested_actions_without_help' from capistrano-2.9.0/lib/capistrano/cli/help.rb:19:in `execute_requested_actions' from capistrano-2.9.0/lib/capistrano/cli/execute.rb:34:in `execute!' from capistrano-2.9.0/lib/capistrano/cli/execute.rb:14:in `execute' from capistrano-2.9.0/bin/cap:4
Sometimes it's very necessary to set the revision, which is being deployed currently.
since version 2.5.8 deploy via scm "bzr" fails because in the bzr checkout command includes a newline after the revision number.
which brakes the command and crashes the deploy.
the fix i applied so far for every new release is simply to replace
line 79
lib/capistrano/recipes/deploy/scm/bzr.rb
with
"-r #{revision}".gsub("\n","")
plz fix this...since it's very annoying to fix it in every new release
In v2.8.0 after I uncomment "load 'deply/assets' "and run 'cap deploy' it shows 'no such file to load' error message. Am I doing anything wrong.
I've seen roles reimplemented three different ways to get them to chef-solo. Half the reason chef-server exists is to get roles to boxes. Capistrano already has the roles information, it'd be great to not have to repeat the information outside of capistrano.
What I do to run chef these days is:
ROLES=$CAPISTRANO:HOSTROLES$ soloist
which then splits the roles env variable and composes a chef run list which installs everything needed to be a server with those roles.
This has been discussed on the lighthouse before.
The error raised when trying to upload a file which doesnt exist is not the desired one. It's easy to reproduce.
task :failing_upload do
upload "no_such_file", "will_never_get_here"
end
Now net-sftp will actually raise the error #<ArgumentError: expected a file to upload>
which is easy to understand and correct. But when that error gets side tracked by Transfer#handle_error
a new (impossible to comprehend) error is created since the @operation
variable for SFTPTransferWrapper
was never set.
/Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:156:in `[]=': undefined method `[]=' for nil:NilClass (NoMethodError)
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:208:in `handle_error'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:48:in `rescue in block in process!'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:44:in `block in process!'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:43:in `loop'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:43:in `process!'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:11:in `process'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/file_transfer.rb:43:in `block in transfer'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:192:in `block in execute_on_servers'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:180:in `each'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:180:in `each_slice'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:180:in `execute_on_servers'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/file_transfer.rb:38:in `transfer'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/file_transfer.rb:26:in `upload'
from ./config/deploy.rb:23:in `block in load'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:139:in `instance_eval'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly_with_callbacks'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:89:in `execute_task'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:46:in `block in execute_requested_actions'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:45:in `each'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:45:in `execute_requested_actions'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/cli/help.rb:19:in `execute_requested_actions_with_help'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:34:in `execute!'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:14:in `execute'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/gems/capistrano-2.6.0/bin/cap:4:in `<top (required)>'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/bin/cap:19:in `load'
from /Users/druiden/.rvm/gems/ruby-1.9.2-p180/bin/cap:19:in `<main>'
Capistrano behaves very badly if any cap
commands happen from a system that has an incorrect clock.
Capistrano should use the clock for the deploying system so that if two cap
commands happen in rapid succession from two different system (one with an incorrect clock) things will work right.
This came up with rubygems/bundler#1142 as an example.
Rollbacks won't work right, for example, if the deploying systems have skewed clocks.
We find that some long-running tasks on one server mean that a connection has timed out on another server that we try to talk to later on in our deployment scripts.
This wouldn't be a big deal as we can use the teardown_connections_to method to remove the dead connections. However, that method uses #close on the connection, which attempts to do a polite SSH protocol termination, ie. sends packets rather than just closing the socket. That is good, but if the connection's already gone dead, it gets an IOError:
/Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/ruby_compat.rb:33:in `select': closed stream (IOError)
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/ruby_compat.rb:33:in `io_select'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/ruby_compat.rb:32:in `synchronize'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/ruby_compat.rb:32:in `io_select'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/transport/packet_stream.rb:73:in `available_for_read?'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/transport/packet_stream.rb:85:in `next_packet'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/transport/session.rb:169:in `poll_message'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/transport/session.rb:164:in `loop'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/transport/session.rb:164:in `poll_message'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/connection/session.rb:451:in `dispatch_incoming_packets'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/connection/session.rb:213:in `preprocess'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/connection/session.rb:197:in `process'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/connection/session.rb:161:in `loop'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/connection/session.rb:161:in `loop_forever'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/connection/session.rb:161:in `loop'
from /Library/Ruby/Gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/connection/session.rb:110:in `close'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:141:in `teardown_connections_to'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:140:in `each'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:140:in `teardown_connections_to'
Since we just want to close the connection, we shouldn't have to do anything if the connection's already closed. I'll send a pull request for a simple fix.
We have hosted our code in github and a sub folder in our repo has the rails app. Looks like capistrano cannot deploy sub folder rails app and fails as it will not be able to find the gemfile.lock in the root of the repo.
Is it possible to have this option?
Hi,
I've been having problems with capistrano where if a command completes quickly on 1 server, but takes more than 40 seconds on another, I get the following error when that 40 seconds is up :
/Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/net-ssh-2.1.4/lib/net/ssh/transport/session.rb:174:in `poll_message': disconnected: Timeout, your session not responding. (2) (Net::SSH::Disconnect)
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/net-ssh-2.1.4/lib/net/ssh/transport/session.rb:164:in `loop'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/net-ssh-2.1.4/lib/net/ssh/transport/session.rb:164:in `poll_message'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/net-ssh-2.1.4/lib/net/ssh/connection/session.rb:451:in `dispatch_incoming_packets'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/net-ssh-2.1.4/lib/net/ssh/connection/session.rb:213:in `preprocess'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/processable.rb:17:in `process_iteration'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/processable.rb:43:in `ensure_each_session'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/processable.rb:41:in `each'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/processable.rb:41:in `ensure_each_session'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/processable.rb:17:in `process_iteration'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/command.rb:165:in `process!'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/command.rb:164:in `loop'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/command.rb:164:in `process!'
from /Users/jon/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/benchmark.rb:308:in `realtime'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/command.rb:163:in `process!'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/command.rb:134:in `process'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/invocation.rb:175:in `run_tree'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:192:in `execute_on_servers'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/loading.rb:93:in `each_slice'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:180:in `each'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:180:in `each_slice'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:180:in `execute_on_servers'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/invocation.rb:173:in `run_tree'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/invocation.rb:145:in `run'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/invocation.rb:89:in `send'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/invocation.rb:89:in `invoke_command'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/recipes/standard.rb:21:in `load'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:139:in `instance_eval'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly_without_callbacks'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:89:in `execute_task'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:46:in `execute_requested_actions_without_help'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:45:in `each'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:45:in `execute_requested_actions_without_help'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/cli/help.rb:19:in `execute_requested_actions'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:34:in `execute!'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:14:in `execute'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.6.0/bin/cap:4
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/bin/cap:19:in `load'
from /Users/jon/.rvm/gems/ree-1.8.7-2011.03/bin/cap:19
For example, if I create a file 'foo' on one server, and run :
cap invoke COMMAND="test -f foo && sleep 45 || echo 'closing'"
on all servers, it will fail with the above error. If 'foo' exists on all servers, so they all take a similar amount of time to complete, it will run fine.
I'm not sure if it's Net::SSH's fault or capistranos - I also opened a ticket on their lighthouse (http://net-ssh.lighthouseapp.com/projects/36253/tickets/33-connections-fall-asleep-and-never-wake-up-if-left-too-long). I've 'fixed' it at the capistrano level at jdelStrother@fe795f9, which works great for me, but I don't know enough about capistrano & net::ssh to say if it's the correct fix.
Hi,
find_servers({:hosts => nil}) should return [], not all available servers.
It appears in my scripts in some cases when :hosts is calculated.
Bertrand
Hello,
I am using capistrano 2.6.0 and bundler 1.0.15 under ruby 1.9.2p180.
When I try to deploy my Rails app, Bundler's after:deploy task fails because current_path
is being expanded to "releases/ls" whereas the release_path
variable has the correct value:
failed: "sh -c 'cd MY_DEPLOY_DIR/releases/ls && bundle install --gemfile MY_DEPLOY_DIR/releases/ls/Gemfile --path MY_DEPLOY_DIR/shared/bundle --deployment --quiet --without development test'" on MY_HOST_NAME
I fixed this issue in Bundler itself but they rejected it, suggesting that I either monkeypatch or get this fixed in Capistrano. So here I am, please help! ๐ป
Thanks for your consideration.
I posted a possible issue on google groups (https://groups.google.com/group/capistrano/browse_thread/thread/ab8223fae9b9e8b0?pli=1), and it's been suggested I post it here and mention @cgriego.
I've just upgraded to rails 3.1, and am getting a warning during
deploy regarding the old rails 3.0 public directories not existing.
Any ideas ?
cap deploy:web:disable
* executing `deploy:web:disable'
# Please add something like this to your site's htaccess to redirect users to the maintenance page.
# More Info: http://www.shiftcommathree.com/articles/make-your-rails-maintenance-page-respond-with-a-503
ErrorDocument 503 /system/maintenance.html
RewriteEngine On
RewriteCond %{REQUEST_URI} !.(css|gif|jpg|png)$
RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ - [redirect=503,last]
servers: ["vs15786"]
** sftp upload #<StringIO:0x00000001c622e8> -> /home/test/shared/system/maintenance.html
/home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:156:in `[]=': undefined method `[]=' for nil:NilClass (NoMethodError)
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:207:in `handle_error'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:48:in `rescue in block in process!'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:44:in `block in process!'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:43:in `loop'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:43:in `process!'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/transfer.rb:11:in `process'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/file_transfer.rb:43:in `block in transfer'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:192:in `block in execute_on_servers'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:180:in `each'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:180:in `each_slice'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/connections.rb:180:in `execute_on_servers'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/file_transfer.rb:38:in `transfer'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/file_transfer.rb:26:in `upload'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/actions/file_transfer.rb:13:in `put'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/namespaces.rb:186:in `method_missing'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/namespaces.rb:186:in `method_missing'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/recipes/deploy.rb:584:in `block (3 levels) in load'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:139:in `instance_eval'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:139:in `invoke_task_directly'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly_with_callbacks'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:89:in `execute_task'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:46:in `block in execute_requested_actions'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:45:in `each'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:45:in `execute_requested_actions'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/cli/help.rb:19:in `execute_requested_actions_with_help'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:34:in `execute!'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/lib/capistrano/cli/execute.rb:14:in `execute'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/gems/capistrano-2.6.0/bin/cap:4:in `<top (required)>'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/bin/cap:19:in `load'
from /home/gucki/.rvm/gems/ruby-1.9.2-p290/bin/cap:19:in `<main>'
#159 line in file lib/capistrano/recipes/deploy/scm/git.rb
the following code will generate a error that is "undefined method `compact'"
execute.join(" && ").compact
Please look at detail report http://pastebin.com/bRxmBJjh
I guess the code should be like this
execute.compact.join(" && ")
The deploy.rb usually contains private informations like passwords to the server and scm, scm addresses and server adresses. If you deploy other projects than Rails, these files may be published into the DOC_ROOT. There is no reason to keep the Capfile and config/deploy.rb on the live server, so it'll be the best solution to remove these files after the deployment.
Here a basic version (I don't know all the details of Capistrano):
namespace :deploy do
task :remove_deployment_files do
run "rm #{latest_release}/Capfile #{latest_release}/config/deploy.rb"
end
end
after 'deploy:update_code', 'deploy:remove_deployment_files'
Capfile:
load 'deploy/assets'
Also tried specyfing rake in deploy.rb:
set :rake, "rake"
Copying the assets tasks to my deploy.rb and changing #{rake} to rake works.
While the deploy:finalize_update
task only runs chmod -R g+w
on the release if :group_writable
is true, the deploy:setup
task will run chmod g+w
on all directories regardless. The option seems counterintuitive given this behavior.
For those who wish to finely manage their permissions, like me, the :group_writable
options would be very useful should it affect all deployment tasks.
I've ran capistrano before on my staging server and was about to deploy on my new production server when I ran into several problems.
This is my cap deploy:check:
several times this error:
bash: /home/apps/.rvm/bin/rvm-shell: No such file or directory
then this conclusion:
The following dependencies failed. Please check them and try again:
--> `/home/apps/manager/releases' does not exist. Please run `cap deploy:setup'. (xxx)
--> You do not have permissions to write to `/home/apps/manager'. (xxx)
--> You do not have permissions to write to `/home/apps/manager/releases'. (xxx)
--> `git' could not be found in the path (212.64.153.253:7694)
--> `gem' command could not be found. Try setting :gem_command (xxx)
--> gem `bundler' >=1.0.11 could not be found (xxx)
obviously the directory errors can be fixed by using cap deploy:setup
The other errors however, are a mystery to me. when I ssh into my server I can easily use the rvm
command and it says it's installed as a function. Furthermore, both git -v
and gem -v
are working correctly. So why can't capistrano use these commands?
Also, I checked for /home/apps/.rvm/bin
, which exists, but there is no rvm-shell command to be found in there? All I see is erb
, gem
, irb
, rake
, rdoc
, ri
, ruby
and testrb
.
My deploy file looks like this:
deploy.rb
bundler details
require "bundler/capistrano"
rvm details
$:.unshift(File.expand_path("./lib", ENV["rvm_path"]))
require "rvm/capistrano"
set :rvm_ruby_string, "1.9.2@manager"
set :rvm_type, :user
application details
set :application, "manager"
repo details
set :scm, :git
set :repository, "xxx"
set :branch, "master"
server details
ssh_options[:forward_agent] = true
set :deploy_to, "/home/apps/#{application}"
set :deploy_via, :remote_cache
set :user, "apps"
set :use_sudo, false
runtime dependencies
depend :remote, :gem, "bundler", ">=1.0.11"
role :web, "xxx"
role :app, "xxx"
role :db, "xxx", primary: true
set :rails_env, "production"
I've installed rvm as a user, which is the only difference from the staging server, so I guess this has something to do with it, but capistrano is looking in the right directory, it just can't find rvm-shell, is this an rvm installation problem, or is it related to my deploy.rb file or anything?
In my (admittedly stupid) setup at work our releases directory looks like:
releases/
project1 -> /home/project1
project2 -> /home/project2
project3 -> /home/project3
20110711220450
20110711220815
It's set up like this due to requirements of the build process. The issue is that with a :keep_releases value of 3, both of the legit releases are removed. While our non-standard set up isn't a Capistrano problem, it seems like it'd be a worthwhile enhancement to refuse to rm -rf the release pointed to by "current" (maybe issue a warning instead). Thanks.
method find_servers_for_task will delegate to find_servers with option :hosts => [] by default. This worked fine up until 2.8.0. In 2.8.0 the first line of method find_servers now returns an empty array, while it should go to the code block where it inspects the given roles to determine the servers.
I've tried adding a few after hooks for the deploy:setup task using the following syntax:
after "deploy:setup", "some:task"
and some:task never fires when running deploy:setup. Other after hooks work fine.
I'm fairly new to capistrano, but this seems like a simple enough use-case that I don't think I've screwed it up :)
I'm getting a strange issue where my after callbacks are being called twice which is causing the deployment to fail as it's trying to create files that it's already created and therefore getting conflicts. Interestingly it is only displaying the triggering after callbacks for <task_name>
message once but is executing the callbacks twice.
My deploy.rb is as follows:
# What is the name of the local application?
set :application, <app_name>
# What user is connecting to the remote server?
set :user, <user>
# Where is the local repository?
set :repository, <repo_path>
set :local_repository, <remote_path>
# What is the production server domain?
role :web, "vserver"
# What remote directory hosts the production website?
set :deploy_to, <deploy_path>
# Is sudo required to manipulate files on the remote server?
set :use_sudo, false
# What version control solution does the project use?
set :scm, :git
set :branch, 'master'
# How are the project files being transferred?
set :deploy_via, :remote_cache
# Maintain a local repository cache. Speeds up the copy process.
set :copy_cache, true
# Ignore any local files?
set :copy_exclude, %w(.git,deployment,.project)
#enabled submodules
set :git_enable_submodules, 1
set :group_writable, false
ssh_options[:forward_agent] = true
after "deploy:setup", "summit:change_permissions", "summit:create_htaccess", "summit:create_shares"
after "deploy:symlink", "summit:change_permissions", "summit:switch_htaccess"
after "deploy:rollback", "summit:change_permissions"
namespace :summit do
#generates default htaccess file to redirect to current
task :create_htaccess, :roles =>:web do
run 'echo -e "Options +FollowSymlinks\nRewriteEngine On\nRewriteCond %{REQUEST_URI} !^/current /\nRewriteCond %{REQUEST_FILENAME} !-f\nRewriteCond %{REQUEST_FILENAME} !-d\nRewriteRule ^(.*)$ /current/\$1 [NC,QSA]\n\nRewriteRule ^(/)?$ /current/ [NC,QSA]" > /path/to/.htaccess'
end
#create required shared folders
task :create_shares, :roles=>:web do
run 'mkdir /path/to/shared/uploads && sudo chmod 777 /path/to/shared/uploads'
run 'mkdir /path/to/shared/batches && sudo chmod 777 /path/to/shared/batches'
run 'mkdir /path/to/shared/config'
end
#update the permissions
task :change_permissions, :roles => :web do
run "sudo chown -R <user>:<user> #{deploy_to}"
run "sudo chmod 755 #{deploy_to}"
run "sudo chmod -R 755 #{deploy_to}releases"
end
#link the admin config file
task :link_admin_config do
run "ln -s #{shared_path}/configs/admin-config.json #{current_release}/admin/config/site/config.json"
end
#upload the admin config files
task :put_admin_config do
if(File.exists?("admin/config/site/config.json"))
upload("admin/config/site/config.json","#{shared_path}/configs/admin-config.json",:via => :scp, :mode => '755')
puts 'Admin config uploaded'
else
puts 'No JSON File To Upload'
end
if(File.exists?("admin/app/assets/css/sass/_colours.scss"))
upload("admin/app/assets/css/sass/_colours.scss","#{shared_path}/configs/admin-colours.scss",:via => :scp, :mode => '755')
puts 'Admin CSS constants uploaded'
else
puts 'No SASS File To Upload'
end
end
#downloads the admin config files
task :get_admin_config do
download("#{shared_path}/configs/admin-config.json","admin/config/site/config.json",:via => :scp)
download("#{shared_path}/configs/admin-colours.scss","admin/app/assets/css/sass/_colours.scss",:via => :scp)
end
#deploys admin config files
task :deploy_admin_config do
put_admin_config
link_admin_config
end
#replaces development htaccess with production version
task :switch_htaccess, :roles => :web do
run "mv #{current_release}/.htaccess #{current_release}/.htaccess-development"
run "cp #{current_release}/.htaccess-production #{current_release}/.htaccess"
end
end
I'm using railsless-deploy as it's a PHP site, with capistrano 2.9.0 on Cygwin
I'm new to capistrano and I having the following problem:
executing locally: "git ls-remote
Error: Could not save revision: Command git ls-remote [email protected]:XXXXX/XXXX.git
master returned status code 32768
If I do a deployment with SVN and Checkout everything works fine.
Note: Git uses ssh_key authentincation...
I'm able to clone the repository if I do the commands on the server. However, when I execute this through
webistrano, server returns:
Error: Could not save revision: Command git ls-remote [email protected]:XXXXX/XXXX.git
The link in the readme points to http://github.com/capistrano/capistrano/wiki/Documentation-v2.x which does not exist. I am not sure if that page used to exist and it was deleted or if this link has always been wrong.
I suspect that, instead, it should point to https://github.com/capistrano/capistrano/wiki
The deploy:assets:precompile task fails because the "rake" variable is not a string but an object of class "Capistrano::Configuration::Namespaces::Namespace".
/lib/capistrano/recipes/deploy/assets.rb, line 40:
run "cd #{latest_release} && #{rake} RAILS_ENV=#{rails_env} #{asset_env} assets:precompile"
It also does not let me set the "rake" variable in deploy.rb file with:
set :rake, "rake".
Using rails 3.10, capistrano 2.8.0.
the symlinks that are created in the finalize_update task in the deploy recipe are hard_coded. However, there is a shared_children variable available that could be used to determine this on the fly. This should make it easier to customize the directories that are symlinked.
I'm looking for a way to get quicker deploys by cutting out unnecessary callbacks on minor deploys. Sometimes I just want to push a small wording change to my staging server and it's awful having to sit through the bundling, asset precompiling, etc.
I thought I found the solution with invoke_task_directly_without_callbacks
but it only disables the callbacks for the given task. Is there any way to disable callbacks for the given task and any subtasks within it?
For example, I'd like to be able to run deploy:update_code
without all the baggage attached to the before/after callbacks attached to deploy:finalize_update
which I can't prevent update_code
from calling.
Here's what I tried:
namespace :deploy do
# For deploys that are just minor updates
# Trying to avoid: updating bundle, updating crontab, precompiling assets
task :minor do
invoke_task_directly_without_callbacks find_task("update_code")
invoke_task_directly_without_callbacks find_task("assets:symlink")
invoke_task_directly_without_callbacks find_task("symlink")
invoke_task_directly_without_callbacks find_task("restart")
end
end
wouldn't it be a good idea to use bundle exec for binaries if bundler is present?
i encountered the problem with
cap deploy:migrations
it justed called rake which messed up some version with rake
so i thought it would be a nice idea in general to always use bundle exec
sure custom recipies have to decide on their own
I've been running into this problem repeatedly after years of using capistrano, dev's either forget to add:
after "deploy:restart", "deploy:cleanup"
Or they just add
set :keep_releases, 5
to their deploy.rb and expect capistrano to start cleaning up after itself, then months later, after many deploys they either run out of space or find discover hundreds of old releases.
I've spoken to a number of long time rails developers and they didn't realize that this was the case either.
I propose we either:
I'm happy to code either solution but I wanted to discuss which is a better approach first.
Using capistrano 2.6.0 and an empty rails-3.1 app I run into the following error when trying to "cap deploy:cold":
- executing `deploy:cold'
- executing `deploy:update'
*\* transaction: start
- executing `deploy:update_code'
executing locally: "git ls-remote [email protected]:cap-blog31.git HEAD"
command finished in 657ms
- executing "git clone -q [email protected]:cap-blog31.git cap_apps/cap-blog31/releases/20110606125643 && cd cap_apps/cap-blog31/releases/20110606125643 && git checkout -q -b deploy 73e34527ee3479b9f12f6867d0e39ef08ea832fb && (echo 73e34527ee3479b9f12f6867d0e39ef08ea832fb > cap_apps/cap-blog31/releases/20110606125643/REVISION)"
servers: ["borg.local"]
[borg.local] executing command
*\* [borg.local :: err] sh: cap_apps/cap-blog31/releases/20110606125643/REVISION: Datei oder Verzeichnis nicht gefunden
command finished in 796ms
**\* [deploy:update_code] rolling back
- executing "rm -rf cap_apps/cap-blog31/releases/20110606125643; true"
servers: ["borg.local"]
[borg.local] executing command
command finished in 30ms
failed: "sh -c 'git clone -q [email protected]:cap-blog31.git cap_apps/cap-blog31/releases/20110606125643 && cd cap_apps/cap-blog31/releases/20110606125643 && git checkout -q -b deploy 73e34527ee3479b9f12f6867d0e39ef08ea832fb && (echo 73e34527ee3479b9f12f6867d0e39ef08ea832fb > cap_apps/cap-blog31/releases/20110606125643/REVISION)'" on borg.local```
The problem is the cd into the cloned directory and then trying to write the REVISIONS file relative from $HOME
If using the cached_copy, capistrano issues a svn update command, if a cached copy is available. But if you switch the branch or tag, that command won't do anything useful. If you use svn switch, it'll switch to the new repo location (if necessary) AND update to the given revision. So there is no downside in using svn switch instead svn update.
See #117
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.