Code Monkey home page Code Monkey logo

capistrano's Introduction

Capistrano: A deployment automation tool built on Ruby, Rake, and SSH.

Gem Version Build Status Code Climate CodersClan

Capistrano is a framework for building automated deployment scripts. Although Capistrano itself is written in Ruby, it can easily be used to deploy projects of any language or framework, be it Rails, Java, or PHP.

Once installed, Capistrano gives you a cap tool to perform your deployments from the comfort of your command line.

$ cd my-capistrano-enabled-project
$ cap production deploy

When you run cap, Capistrano dutifully connects to your server(s) via SSH and executes the steps necessary to deploy your project. You can define those steps yourself by writing Rake tasks, or by using pre-built task libraries provided by the Capistrano community.

Tasks are simple to make. Here's an example:

task :restart_sidekiq do
  on roles(:worker) do
    execute :service, "sidekiq restart"
  end
end
after "deploy:published", "restart_sidekiq"

Note: This documentation is for the current version of Capistrano (3.x). If you are looking for Capistrano 2.x documentation, you can find it in this archive.


Contents

Features

There are many ways to automate deployments, from simple rsync bash scripts to complex containerized toolchains. Capistrano sits somewhere in the middle: it automates what you already know how to do manually with SSH, but in a repeatable, scalable fashion. There is no magic here!

Here's what makes Capistrano great:

Strong conventions

Capistrano defines a standard deployment process that all Capistrano-enabled projects follow by default. You don't have to decide how to structure your scripts, where deployed files should be placed on the server, or how to perform common tasks: Capistrano has done this work for you.

Multiple stages

Define your deployment once, and then easily parameterize it for multiple stages (environments), e.g. qa, staging, and production. No copy-and-paste necessary: you only need to specify what is different for each stage, like IP addresses.

Parallel execution

Deploying to a fleet of app servers? Capistrano can run each deployment task concurrently across those servers and uses connection pooling for speed.

Server roles

Your application may need many different types of servers: a database server, an app server, two web servers, and a job queue work server, for example. Capistrano lets you tag each server with one or more roles, so you can control what tasks are executed where.

Community driven

Capistrano is easily extensible using the rubygems package manager. Deploying a Rails app? Wordpress? Laravel? Chances are, someone has already written Capistrano tasks for your framework of choice and has distributed it as a gem. Many Ruby projects also come with Capistrano tasks built-in.

It's just SSH

Everything in Capistrano comes down to running SSH commands on remote servers. On the one hand, that makes Capistrano simple. On the other hand, if you aren't comfortable SSH-ing into a Linux box and doing stuff on the command-line, then Capistrano is probably not for you.

Gotchas

While Capistrano ships with a strong set of conventions that are common for all types of deployments, it needs help understanding the specifics of your project, and there are some things Capistrano is not suited to do.

Project specifics

Out of the box, Capistrano can deploy your code to server(s), but it does not know how to execute your code. Does foreman need to be run? Does Apache need to be restarted? You'll need to tell Capistrano how to do this part by writing these deployment steps yourself, or by finding a gem in the Capistrano community that does it for you.

Key-based SSH

Capistrano depends on connecting to your server(s) with SSH using key-based (i.e. password-less) authentication. You'll need this working before you can use Capistrano.

Provisioning

Likewise, your server(s) will likely need supporting software installed before you can perform a deployment. Capistrano itself has no requirements other than SSH, but your application probably needs database software, a web server like Apache or Nginx, and a language runtime like Java, Ruby, or PHP. These server provisioning steps are not done by Capistrano.

sudo, etc.

Capistrano is designed to deploy using a single, non-privileged SSH user, using a non-interactive SSH session. If your deployment requires sudo, interactive prompts, authenticating as one user but running commands as another, you can probably accomplish this with Capistrano, but it may be difficult. Your automated deployments will be much smoother if you can avoid such requirements.

Shells

Capistrano 3 expects a POSIX shell like Bash or Sh. Shells like tcsh, csh, and such may work, but probably will not.

Quick start

Requirements

  • Ruby version 2.0 or higher on your local machine (MRI or Rubinius)
  • A project that uses source control (Git, Mercurial, and Subversion support is built-in)
  • The SCM binaries (e.g. git, hg) needed to check out your project must be installed on the server(s) you are deploying to
  • Bundler, along with a Gemfile for your project, are recommended

Install the Capistrano gem

Add Capistrano to your project's Gemfile using require: false:

group :development do
  gem "capistrano", "~> 3.17", require: false
end

Then run Bundler to ensure Capistrano is downloaded and installed:

$ bundle install

"Capify" your project

Make sure your project doesn't already have a "Capfile" or "capfile" present. Then run:

$ bundle exec cap install

This creates all the necessary configuration files and directory structure for a Capistrano-enabled project with two stages, staging and production:

├── Capfile
├── config
│   ├── deploy
│   │   ├── production.rb
│   │   └── staging.rb
│   └── deploy.rb
└── lib
    └── capistrano
            └── tasks

To customize the stages that are created, use:

$ bundle exec cap install STAGES=local,sandbox,qa,production

Note that the files that Capistrano creates are simply templates to get you started. Make sure to edit the deploy.rb and stage files so that they contain values appropriate for your project and your target servers.

Command-line usage

# list all available tasks
$ bundle exec cap -T

# deploy to the staging environment
$ bundle exec cap staging deploy

# deploy to the production environment
$ bundle exec cap production deploy

# simulate deploying to the production environment
# does not actually do anything
$ bundle exec cap production deploy --dry-run

# list task dependencies
$ bundle exec cap production deploy --prereqs

# trace through task invocations
$ bundle exec cap production deploy --trace

# lists all config variable before deployment tasks
$ bundle exec cap production deploy --print-config-variables

Finding help and documentation

Capistrano is a large project encompassing multiple GitHub repositories and a community of plugins, and it can be overwhelming when you are just getting started. Here are resources that can help:

Related GitHub repositories:

  • capistrano/sshkit provides the SSH behavior that underlies Capistrano (when you use execute in a Capistrano task, you are using SSHKit)
  • capistrano/rails is a very popular gem that adds Ruby on Rails deployment tasks
  • mattbrictson/airbrussh provides Capistrano's default log formatting

GitHub issues are for bug reports and feature requests. Please refer to the CONTRIBUTING document for guidelines on submitting GitHub issues.

If you think you may have discovered a security vulnerability in Capistrano, do not open a GitHub issue. Instead, please send a report to [email protected].

How to contribute

Contributions to Capistrano, in the form of code, documentation or idea, are gladly accepted. Read the DEVELOPMENT document to learn how to hack on Capistrano's code, run the tests, and contribute your first pull request.

License

MIT License (MIT)

Copyright (c) 2012-2020 Tom Clements, Lee Hambley

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

capistrano's People

Contributors

aeroastro avatar ain avatar andytinycat avatar artemeff avatar betesh avatar blackxored avatar dbenamydd avatar infog avatar kaikuchn avatar killthekitten avatar kirs avatar leehambley avatar marcovtwout avatar mattbrictson avatar miry avatar mpapis avatar olleolleolle avatar poctek avatar quixoten avatar richardkmichael avatar rlisowski avatar rosenfeld avatar seenmyfate avatar signedbyte avatar snappedtogrid avatar teohm avatar townsen avatar troelskn avatar will-in-wi avatar y9v avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

capistrano's Issues

regression: git submodule update --recursive doesn't work on git 1.6

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.

invalid byte sequence

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' * executingdeploy'
* executing deploy:update' ** transaction: start * executingdeploy:update_code'
triggering before callbacks for deploy:update_code' * executinginstall_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

  • executing `staging'
  • executing `deploy'
  • executing `deploy:update'
    ** transaction: start
  • executing deploy:update_code' triggering before callbacks fordeploy: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 UTF-8)

Placeholder to access roles assigned to a host - $CAPISTRANO:HOSTROLES$

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.

Task deploy:setup doesn't respect :group_writable

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.

$LANG var and Capistrano

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!

1) Tested if the Capistrano preserver the $LANG var

COMMAND="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

2) Tested running the command on the local machine with the $LANG var empty

export 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 `'

Provide separate arguments per scm command

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.

find_servers_for_task doesn't work anymore in 2.8.0

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.

Rails 3.1 upgrade and asset folders

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 ?

  • executing `deploy:finalize_update'
  • executing "chmod -R g+w /home/.../releases/20110809145825"
    servers: ["..."]
    [...] executing command
    command finished in 513ms
  • executing "rm -rf /home/.../releases/20110809145825/log /home/.../
    releases/20110809145825/public/system /home/.../releases/
    20110809145825/tmp/pids &&\n mkdir -p /home/.../releases/
    20110809145825/public &&\n mkdir -p /home/.../releases/
    20110809145825/tmp &&\n ln -s /home/.../shared/log /home/.../
    releases/20110809145825/log &&\n ln -s /home/.../shared/system /
    home/.../releases/20110809145825/public/system &&\n ln -s /
    home/.../shared/pids /home/.../releases/20110809145825/tmp/pids"
    servers: ["..."]
    [...] executing command
    command finished in 1409ms
  • executing "find /home/.../releases/20110809145825/public/images /
    home/.../releases/20110809145825/public/stylesheets /home/.../releases/
    20110809145825/public/javascripts -exec touch -t 201108091459.21 {}
    ';'; true"
    servers: ["..."]
    [...] executing command
    ** [out :: ...] find: /home/.../releases/20110809145825/public/images
    ** [out :: ...] : No such file or directory
    ** [out :: ...] find: /home/.../releases/20110809145825/public/
    stylesheets: No such file or directory
    ** [out :: ...] find: /home/.../releases/20110809145825/public/
    javascripts: No such file or directory
    command finished in 655ms

task deploy:web:disable broken on 2.6.0

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>'

Disabling all callbacks on *and in* a task

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

`set :git_submodules_recursive, false` is broken

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.

Introduce Capistrano properly

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.

bzr deploy fails because wrong \n in command

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

Causing trouble on Jruby

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.

Error: Could not save revision: Command git ls-remote git ... master returned status code 32768

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

Do subdirectories of "releases" have to have timestamps as names or not?

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.

Rake variable incorrect in deploy:assets:precompile

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.

Capistrano uses wrong SSH keys

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")
]
}

capistrano errors out with rvm-shell command not found

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?

Delete Capfile & deploy.rb after deployment

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'

deploy:cleanup should not remove "current"

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.

Capistrano remote_cache deployment strategy has problems with 'cached-copy' directory

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?

Staging support

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?

CLI behavior on Capistrano doesn't seem to be the same as that of an SSH connection.

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.

Use svn switch instead of svn update for cached_copy

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.

Callbacks being run twice

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

Carry on if connection teardown finds the connection has already timed out

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.

Feature request: Base symlinking on the shared_children variable

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.

Transfer + sftp error handling broken

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>'

find_servers(:hosts => nil)

Hi,

find_servers({:hosts => nil}) should return [], not all available servers.

It appears in my scripts in some cases when :hosts is calculated.

Bertrand

After hook for deploy:setup doesn't fire

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 :)

DB Server Requires Ruby/Bundler/Gems

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:

  • the correct Ruby version
  • (more than likely) the correct Bundler version
  • all the gem dependencies met

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.

deploy:migrate task throws error due to bad 'rake' usage

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

Deploying sub folders of git repository

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?

current_path is "releases/ls" whereas release_path is correct

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.

Rake not found in precompile assets tasks

  • executing "cd releases/20110926100819 && #Capistrano::Configuration::Namespaces::Namespace:0x007fda69ed0b48 RAILS_ENV=staging RAILS_GROUPS=assets assets:precompile"

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.

bundle exec for binaries

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

Differing command durations lead to Net::SSH::Disconnect

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.

Capistrano should get the release date from the remote system.

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.

cap deploy:cold fails with git

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

The git submodule command doesn't seem to have a --recursive option

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.

cap deploy should run deploy:cleanup by default

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:

  • enable cleanup after a deploy by default
  • or if keep_releases is explicitly set in deploy.rb then we hook in the cleanup task

I'm happy to code either solution but I wanted to discuss which is a better approach first.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.