RVM, bundler and hudson configuration

102 views
Skip to first unread message

tommy chheng

unread,
Aug 19, 2010, 9:25:52 PM8/19/10
to rvm (Ruby Version Manager)
I'm having an issue with hudson, RVM and bundler.

I have two ruby apps(lets call, A and B) listed on hudson.
A is running fine with hudson.
When I try to run B on hudson, it tries to use A's rvm gempath.
In the Execute Shell Script, I have:
rvm use 1.9.2 && rvm gemset use project_B && bundle install

But in the console output, it says:
Your bundle was installed to `/usr/local/rvm/gems/ruby-1.9.2-
p0@project_A`

Why is project_A's env variable for the gempath interfering?

Darcy Laycock

unread,
Aug 19, 2010, 9:36:49 PM8/19/10
to rvm (Ruby Version Manager)
Since it doesn't look like you're sourcing rvm inside the shell
script, it's most
likely calling rvm as a binary (vs. shell function) hence it doesn't
actually execute
it.

The solutions are:
- make the shebang "#!/usr/bin/env rvm-shell 1.9.2"
- use "rvm 1.9.2 exec bundle install"
- make the shebang "#!/bin/bash", source "/usr/local/rvm/scripts/rvm"
and use the above after that.

Or, wait until I write a plugin that lets you just pass in the ruby
string + the shell command :P

lusis

unread,
Aug 20, 2010, 12:02:57 AM8/20/10
to rvm (Ruby Version Manager)
I run it like so:

step #1 -
#!/bin/bash -l
rvm use 1.8.7
rvm gemset create ${BUILD_TAG}
rvm gemset use ${BUILD_TAG}
gem install bundler --pre
bundle install
bundle check

step #2 -
#!/bin/bash -l
rvm use 1.8.7@${BUILD_TAG}
bundle exec rake test

step #3 -
#!/bin/bash -l
rvm use 1.8.7@${BUILD_TAG}
bundle exec rake hudson:coverage:unit

step #4 -
#!/bin/bash -l
rvm use 1.8.7
rvm --force gemset delete ${BUILD_TAG}

I have build plans for each of the ruby vms. Step 3 only applies to
mri 1.8.7 because of bugs in rcov. The rest are just steps 1,2,4 with
the version changed.

lusis

unread,
Aug 19, 2010, 10:50:20 PM8/19/10
to rvm (Ruby Version Manager)
I've actually just been putting #!/bin/bash -l in my hudson steps for
now. Works great. Then I generate a new gemset based on the jobname
variable and run bundle install. Final step in the job destroys the
gemset.

Tommy Chheng

unread,
Aug 20, 2010, 1:04:09 PM8/20/10
to rubyversi...@googlegroups.com
I'm trying this as one script in hudson:
#!/bin/bash -l
source "/usr/local/rvm/scripts/rvm"
rvm use ruby-1.9.2

rvm gemset create ${BUILD_TAG}
rvm gemset use ruby-1.9.2@${BUILD_TAG}
gem install rake

gem install bundler --pre
bundle install
bundle check
bundle exec rake test

The output is:
info: Using ruby 1.9.2 p0

info: Gemset 'hudson-project-56' created.
 [31mCould not find rake-0.8.7 in any of the sources [0m

I'm sure rake is installed. It looks like it's not using the right gemset?
Any ideas?

Darcy Laycock

unread,
Aug 20, 2010, 10:21:55 PM8/20/10
to rvm (Ruby Version Manager)
Just to confirm - the hudson user is a member of the rvm group?
If not, that may be an issue.

Try using a script like:

#!/bin/bash -l
source "/usr/local/rvm/scripts/rvm"
rvm use ruby-1.9.2@${BUILD_TAG} --create
gem install rake
gem install bundler --pre
bundle install
bundle check
bundle exec rake test

The use-style syntax is faster + our preferred syntax fwiw.
> >> rvm use 1.9.2&&  rvm gemset use project_B&&  bundle install

lusis

unread,
Aug 21, 2010, 10:30:57 PM8/21/10
to rvm (Ruby Version Manager)
You shouldn't need to install rake. RVM installs it as part of the
base ruby vm unless something didn't work when you initially installed
it. I would try with 1.9.1 and also reinstall 1.9.2 just to make sure.
> >> rvm use 1.9.2&&  rvm gemset use project_B&&  bundle install

Tommy Chheng

unread,
Aug 23, 2010, 5:38:54 PM8/23/10
to rubyversi...@googlegroups.com
Thanks, found the source of the error.

Somewhere in the configuration, RUBYOPT was being set to project A's
gempath even though I was running tests for project B.

I just export RUBYOPT="" and both hudson tests are working with RVM.

lusis

unread,
Aug 24, 2010, 8:04:32 PM8/24/10
to rvm (Ruby Version Manager)

I was getting a similar problem initially. I just set my default to
system and the bash -l took care of the rest.
Reply all
Reply to author
Forward
0 new messages