Bundler support for Capistrano 3.x
Bundler specific tasks for Capistrano v3:
$ cap production bundler:install
It also prefixes certain binaries to use
bundle exec.
Add these lines to your application's Gemfile [Recommended]:
gem 'capistrano', '~> 3.6' gem 'capistrano-bundler', '~> 2.0'
And then execute:
$ bundle
Or install it yourself as:
$ gem install capistrano-bundler
Require in
Capfileto use the default task:
require 'capistrano/bundler'
The task will run before
deploy:updatedas part of Capistrano's default deploy, or can be run in isolation with
cap production bundler:install.
In order for Bundler to work efficiently on the server, its project configuration directory (
/.bundle/) should be persistent across releases. You need to add it to the
linked_dirsCapistrano variable:
Capistrano 3.5+:
# config/deploy.rbappend :linked_dirs, '.bundle'
Capistrano < 3.5:
# config/deploy.rbset :linked_dirs, fetch(:linked_dirs, []) << '.bundle'
It will still work fine with non-persistent configuration directory, but then it will have to re-resolve all gems on each deploy.
By default, the plugin adds
bundle execprefix to common executables listed in
bundle_binsoption. This currently applies for
gem,
rakeand
rails.
You can add any custom executable to this list:
set :bundle_bins, fetch(:bundle_bins, []).push('my_new_binary')
Configurable options:
set :bundle_roles, :all # this is default set :bundle_config, { deployment: true } # this is default set :bundle_servers, -> { release_roles(fetch(:bundle_roles)) } # this is default set :bundle_binstubs, -> { shared_path.join('bin') } # default: nil set :bundle_gemfile, -> { release_path.join('MyGemfile') } # default: nil set :bundle_path, -> { shared_path.join('bundle') } # this is default. set it to nil to use bundler's default path set :bundle_without, %w{development test}.join(':') # this is default set :bundle_flags, '--quiet' # this is default set :bundle_env_variables, {} # this is default set :bundle_clean_options, "" # this is default. Use "--dry-run" if you just want to know what gems would be deleted, without actually deleting them set :bundle_check_before_install, true # default: true. Set this to false to bypass running `bundle check` before executing `bundle install`
You can parallelize the installation of gems with bundler's jobs feature. Choose a number less or equal than the number of cores your server.
set :bundle_jobs, 8 # default: 4, only available for Bundler >= 1.4
To generate binstubs on each deploy, set
:bundle_binstubspath:
set :bundle_binstubs, -> { shared_path.join('bin') }
In the result this would execute the following bundle commands on all servers (actual paths depend on the real deploy directory):
$ bundle config --local deployment true $ bundle config --local gemfile /my_app/releases/20130623094732/MyGemfile $ bundle config --local path /my_app/shared/bundle $ bundle config --local without "development test" $ bundle install --quiet --binstubs /my_app/shared/bin
If any option is set to
nilit will be excluded from the final bundle commands.
If you want to clean up gems after a successful deploy, add
after 'deploy:published', 'bundler:clean'to config/deploy.rb.
Downsides to cleaning:
The
bundle_env_variablesoption can be used to specify any environment variables you want present when running the
bundlecommand:
# This translates to NOKOGIRI_USE_SYSTEM_LIBRARIES=1 when executed set :bundle_env_variables, { nokogiri_use_system_libraries: 1 }
git checkout -b my-new-feature)
git commit -am 'Add some feature')
git push origin my-new-feature)