noting that rvm's optional .ruby-version file can hinder a Capistrano Rails deploy

62 views
Skip to first unread message

Gallagher Polyn

unread,
Apr 16, 2014, 7:02:29 PM4/16/14
to capis...@googlegroups.com
Was getting deployment failure message rbenv: version `ruby-2.1.0' is not installed, when none of my configuration made reference to that ruby version. But my local dev ruby (2.1.0) had been added to the project repo in a .ruby-version file and after I removed the file from the repo I redeployed successfully.

Hoping this will prove useful to note for someone in the future.

Versions:
  • Ruby 2.1.0 (recorded on .ruby-version from local dev environment) vs. Ruby 2.1.1 on deployment environment
  • Capistrano 3.1
  • Rails 4
Platform:
  • Working on OS X 10.8
  • Deploying to Ubuntu 12.04 LTS
Logs:
INFO [ea6cc465] Running /usr/bin/env sudo /etc/init.d/unicorn_app1_production restart on 33.33.33.33
DEBUG [ea6cc465] Command: ( RBENV_ROOT=~/.rbenv RBENV_VERSION=2.1.1 /usr/bin/env sudo /etc/init.d/unicorn_app1_production restart )
DEBUG [ea6cc465] Couldn't reload, starting 'cd /srv/www/app1/current;  bundle exec unicorn -D -c /srv/www/app1/shared/config/unicorn.rb -E production' instead
DEBUG [ea6cc465] rbenv: version `ruby-2.1.0' is not installed
DEBUG [ea6cc465] rbenv: version `ruby-2.1.0' is not installed

            Donovan Bray

            unread,
            Apr 16, 2014, 10:13:34 PM4/16/14
            to capis...@googlegroups.com
            I don't allow .rvmrc .rbenv-version .ruby-version or .ruby-gemset to be checked into the repo. I preemptively add them to the .gitignore even if we don't use them.  If developers want them they are allowed to add them with the extension .template. Like .ruby-version.template

            I also have a rule of no ruby switchers in production. I firmly believe if you need a different version of ruby on the box get a different box. I would rather deal with server virtualization than with manhandling ruby switchers with capistrano and god. Having no ruby switchers in prod provides another layer of protection for someone adding the latest flavor of the month ruby switcher file into the repo. 

            Developers can copy or symlink in their local checkout whichever one they want and it doesn't get accidentally checked in and foul everybody else up. It also ensures there are no surprises in production by a developer who isn't paying attention and something sneaks through peer review. 

            I've also been known to leave angry tirades in comments in the template files that developers should only change them if they are willing to do ALL of the work of upgrading every ruby version in our pre-production, continuous integration, and production servers.   

            Not surprisingly those files are rarely changed by anybody but me. We have more consistency and no more issues caused by differing versions of ruby between Dev, pre-prod, and production. 
            --
            You received this message because you are subscribed to the Google Groups "Capistrano" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
            To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/c88b636c-5d9f-424c-84b0-9c83988fcc7f%40googlegroups.com.
            For more options, visit https://groups.google.com/d/optout.
            Reply all
            Reply to author
            Forward
            0 new messages