I already posted that I've been using Jenkins and RVM. The theory is great: Jenkins lets you set up lots of recurring jobs and have one dashboard to see that all of your software is basically working, while RVM allows you to choose a different Ruby version and gemset for each project that might need that.
The first Jenkins job I set up seemed to use the RVM Ruby-1.8.7 just fine, but when I tried to set up a second job that required Ruby-1.9.2, I never could get it working. First it tried to use the system ruby, which I blew away. Then I had hours tracking down references to the system ruby. The command "rvm use 1.9.2" appeared to work and chose the right rvm ruby directory. But even when it worked, when the very next command run by jenkins was "ruby -v", the machine either couldn't find the ruby install at all, or found the system one, but never the one just successfully activated by RVM. Even more frustrating, this worked at the command line, but not when running a job from Jenkins. (If anybody can explain how Jenkins runs jobs differently and what effect that has on context, I'd love to know -- having a model of what's going on would help.)
Finally I discovered "rvm-shell", which can force execution of a command within the context of what RVM set up. So now every line of the jenkins job script that uses ruby, bundle or rake, is wrapped in that:
rvm use 1.9.2@profiles rvm-shell -c "ruby -v" rvm-shell -c "bundle install" rvm-shell -c "rake db:migrate" # Finally, run your tests rvm-shell -c "rake"
It worked. 56 is the magic number -- that is, build #56 was the first one to work on this project. Phew.
1 comment:
Hi Lisa,
long time no see!
Anyway, to your Jenkins problem. If you haven't done it already already, check that your Jenkins environment variables are the same as in your command line session. I bet things like PATH, LANG and a bunch of others will be different.
To see what environment a Jenkins job runs with, just create a Build task that executes a shell task that prints all environment variables. Depending on your shell it could be as simple as "set". Then compare what Jenkins console shows for your environment vs your logged in session.
Anyways, that was how I solved my build problems with Jenkins.
Post a Comment