Doesn't play nicely with RVM

Question

Doesn't play nicely with RVM

codykrieger opened this issue 13 years ago · comments

I can't seem to get whiskey_disk to deploy to servers with RVM installed.

I read about the ~/.ssh/environment thing in the FAQ, so I figured I could just source a .bashrc or .zshrc that had the necessary RVM lines in it, but it doesn't seem to work for me. I always end up getting the following regardless of what I've sourced:

...

Running rake deploy:post_setup...
zsh:1: command not found: rake

Results:
codykrieger.com => failed.
Total: 1 deployment, 0 successes, 1 failure.

Does anyone have any experience using Whiskey Disk with RVM? This is the only thing keeping me from switching away from Capistrano, which I've developed a loathing for.

Thanks!

Rick Bradley · Answer 1 · Sat Apr 30 2011 00:02:27 GMT+0800 (China Standard Time)

Cody -- thanks for reporting this. I'm probably the most likely person to look into this and I'm just about to get on the road to go up to Floyd, VA, this weekend for a Code Retreat. I'll probably be able to look at this Monday I'm guessing. In the meantime could you make a gist (or otherwise attach) with:

the output of your wd run with the --debug flag set
the contents of your deploy.yml (anonymized if you need to)
if you're using a post_setup_script or post_deploy_script, the contents of that

Thanks!
Rick

Cody Krieger · Answer 2 · Sat Apr 30 2011 04:52:06 GMT+0800 (China Standard Time)

Sure!

Here's everything you asked for in gist form: https://gist.github.com/949016

The deploy_magic.sh file has worked to temporarily source RVM and perform operations, but Whiskey Disk still has the same issue regardless. UPDATE: To clarify, I mean running deploy_magic.sh as a post_setup/deploy_script.

Thanks! I appreciate you taking a look.

Rick Bradley · Answer 3 · Fri May 06 2011 22:43:14 GMT+0800 (China Standard Time)

Sorry it took me this long to get back to this. After looking things over here's what I'm thinking:

the "normal" way I've seen rvm used is via inclusion of /usr/local/lib/rvm (or the same hook in another location) into the environment at login time, by sourcing that rvm file in the login scripts (.bash_profile, .bashrc, .zshrc?, etc.)
since the rvm file is basically "sourced" (i.e., it must be modifying the parent process' environment) it's difficult to run it in a subprocess and get the desired results

I'm thinking it might be easiest to try to add this to the tail end of .zshrc for the user account being deployed to:

source "/usr/local/lib/rvm"

I'm presuming that zsh (I'm a bash user so I'm not certain of the intricacies of zsh) works similar to bash in that .bashrc, if I remember correctly, is run on all logins, while .bash_profile is only run on logins where there is an interactive terminal (by default ssh running a command does not get an interactive terminal, which is the situation wd causes).

If the .zshrc modification works then, cool. If not, we might start working through some of the ideas here to see what we can get:

http://matthew.mceachen.us/blog/howto-make-system-wide-rvm-installations-work-with-cron-monit-delayed_job-and-passenger-1021.html

Another note is that you appear to be using bundler. The way I typically recommend to work with bundler is two-fold:

I usually recommend declaring a post_setup_script and a post_deploy_script (the hope is that sometime in the near future setup is fully rolled into deploy so two scripts won't be necessary, but that's a side note) where the script just contains whatever bundler incantation people expect before running whatever it is they do for their post tasks.
Rather than having rake tasks that shell out to 'bundle exec' (I've seen this frequently for some reason), that the main application Rakefile just properly includes bundler at the top. Depending on the version of bundler, of course, this might be a different incantation, but there should be one that works.

Cody Krieger · Answer 4 · Sat May 07 2011 03:22:04 GMT+0800 (China Standard Time)

No worries!

I actually do have a line that sources rvm at the end of my .zshrc:

if [[ -s "/usr/local/lib/rvm" ]] ; then source "/usr/local/lib/rvm" ; fi

.zshrc is supposed to always be executed like you said, which is why this is so confusing. Running scripts that just echo environment variables in post_setup and post_deploy seem to indicate that my PATH is not being set according to my preferences, and rvm has not been sourced.

What you said about Rakefiles including bundler makes sense, though - I hadn't thought of doing it that way.

נυαη נυαηѕση · Answer 5 · Thu May 12 2011 08:54:36 GMT+0800 (China Standard Time)

When running commands over ssh it will not source your .rc files. You can always set VARIABLE=VALUE in ~/.ssh/environment but that is a bit lame.

I personally would like to see the ability to set the rake command much like capistrano and vlad allow.
Also, it would be useful to set a command that runs prior to any cd'ing around. This allows one to source an rvmrc before cd'ing into the deploy dir (this allows rvm to pickup the rvmrc and paths and ruby are set).

This allows you to accomplish what you suggested with the Rakefile. Without sourcing rvm first, you wont be able to find rake, and adding bundler to Raketab is moot.

If anything it makes the deployment more flexible if people choose to use it.

Brandon Valentine · Answer 6 · Wed Jun 29 2011 03:40:35 GMT+0800 (China Standard Time)

I ran into this same issue and several things helped clear it up. All of these were required:

Move the rvm script-sourcing to .bashrc from .bash_profile. Make it the last line in that file.
Login interactively as the deployment user and run the command rvm --default 1.9.2@gemset or whatever version and/or gemset you need to run
Make sure any post-setup and post-deploy scripts start with #!/bin/bash, not #!/bin/sh, because /bin/sh may not source .bashrc.

Give that a try.

Brandon Valentine · Answer 7 · Wed Jun 29 2011 06:52:35 GMT+0800 (China Standard Time)

Also beware that if you're on Ubuntu, the default .bashrc from /etc/skel will return on the first line if in a non-interactive shell. You need to place your rvm setup prior to that return, or comment it out entirely.

Hope this helps,

Brandon

Hedgehog · Answer 8 · Wed Jun 29 2011 07:05:27 GMT+0800 (China Standard Time)

At least on Ubuntu/debian, I wonder if using this in any SSH scripting won't help?

export DEBIAN_FRONTEND=noninteractive

Cody Krieger · Answer 9 · Wed Jun 29 2011 11:13:34 GMT+0800 (China Standard Time)

Thanks @BrandonValentine! I'll try that some time soon.

Sylvain Desbureaux · Answer 10 · Thu Jul 28 2011 04:40:22 GMT+0800 (China Standard Time)

fyi, I proposed a pull request (#24) to solve this issue by adding the way to choose the rake executable. Feel free to comment it.

Deleted user · Answer 11 · Fri Sep 30 2011 02:19:35 GMT+0800 (China Standard Time)

Am interested in feedback as to whether allowing setting the rake executable (see pull request 24) addresses this issue.
Best,
Rick

Brandon Valentine · Answer 12 · Sat Oct 01 2011 10:17:28 GMT+0800 (China Standard Time)

I'm not using the rake tasks for my post-setup/post-deploy, but what did end up fixing all of my issues is just to religiously preface any and all Ruby commands in my post-setup/post-deploy scripts with rvm exec. It would stand to reason that doing the same for the rake executable would also solve the problem for the rake tasks. It could make sense to take this a step further and execute the post-setup/post-deploy bash scripts via rvm exec as well. That would eliminate the need for users to call rvm exec numerous times from their post-setup/post-deploy scripts and eliminate a bunch of subshells. In other words, allow the user to specify a prefix for any and all commands post-setup or post-deploy, whether rake or bash scripts.

Rick Bradley · Answer 13 · Sat Oct 01 2011 12:57:37 GMT+0800 (China Standard Time)

Somehow I'm skeptical that rvm is working properly if it requires prefacing anything one does with 'rvm exec'.

Deleted user · Answer 14 · Sun Oct 02 2011 09:59:18 GMT+0800 (China Standard Time)

Note that it is possible to run an arbitrary rake by using a post_setup_script or a post_deploy_script. If rvm truly requires every interaction to be prefaced with 'rvm exec' then it appears to me to be mis-designed. I'm not inclined to design features to enable use of mis-designed software. Since there is a workaround, I am closing this issue.

Rick