Please use .ruby_version when available

[rosenfeld]

I know there are other closed issues with regards to this subject, but I have a situation where I think it justifies changing this plugin to look first for a .ruby_version file.

In our Capistrano recipes we first stop the sidekiq worker before proceeding with the deploy. Now, consider when we are upgrading Ruby from 2.2.4 to 2.3.0 with rbenv. The capistrano-sidekiq gem will run "bundle exec sidekiqctl stop..." before the deploy starts. By that time, .ruby_version points to 2.2.4 and bundle install was run previously for the current path and it should just work. But since capistrano-rbenv is overriding the Ruby version to 2.3.0 this command will fail because bundle install wasn't executed yet before trying to stop sidekiq and it will yield to an error which I had to fix manually by running bundle in that path first for the newer Ruby.

If the project .ruby_version was used when present it should just work transparently...

[mattbrictson]

This may not work in your case, but have you considered enabling rbenv for non-interactive shells on your server and dropping capistrano-rbenv altogether?

For example, in my deployments where I am using Ubuntu 14.04 and have rbenv installed in $HOME/.rbenv, I just add this to the very top (i.e. preceding the interactive shell check) of my deployer user's .bashrc:

if [ -d $HOME/.rbenv ]; then
  export PATH="$HOME/.rbenv/bin:$PATH"
  eval "$(rbenv init -)"
fi

Then all my Capistrano deployments seamlessly use rbenv, and I get the automatic .ruby_version behavior like you described. And I haven't needed the capistrano-rbenv gem at all.

[rosenfeld]

@mattbrictson indeed, this is something I may consider doing. I measured the performance for setting up rbenv and it only takes about 2ms, which is reasonable enough I guess as a payload for the other commands not relying on rbenv...

[wojtha]

@rosenfeld What about this?

set :rbenv_ruby, File.read('.ruby-version')

[rosenfeld]

This only works when Capistrano is part of the application's repository. In our case, we use Capistrano in a separate project, integrated with Chef to handle both server configuration and deploy with a single command. This project handles different applications possibly running on different Ruby versions. That's why this solution doesn't work for us.

[spikeheap]

Hi, we came up against this issue even with Capistrano being part of the application's repository.

To reproduce:

1. Create a task which uses bundle, and trigger it after "deploy:starting".
2. Bump the Ruby version in the Cap config, Gemfile (and .ruby-version)
3. Run a deploy.

Expected behaviour:

The deploy succeeds

Experienced behaviour:

The deploy fails because the Gemfile specifies the current version of Ruby, but rbenv is running with the bumped version.

I've submitted #67 which resolves the issue for us by removing the requirement that rbenv_ruby is set, and allowing rbenv to determine the Ruby version if it's not present.

The behaviour isn't altered when rbenv_ruby is set.

[spikeheap]

Sorry for the pre-completion comment, updated the above to make more sense!

[mattbrictson]

Closed via #67

[mattbrictson]

Released in v2.1.0 🚢