Testing against Rubinius on Travis CI
Tweet Follow @hazula
Background:
Fourteen (14) days ago, my Rubinius builds on Travis CI began erroring
Since, I can’t seem to find a write-up on the final state of affairs, I’ve written-up a summary of what I did, and how I got the tests reliably passing one (1) day ago.
Update 2014-02-10
The Rubinius 2.2.5 release now includes the standard library, and so, you no longer need a special :rbx group, only to specify rbx-2 in your travis.yml
Standard library gems ‘racc’, ‘minitest’, and ‘rubysl-test-unit’ are now pre-installed, in addition to json and the RubySL gems. (Brian Shirai)
The ‘rbx-2’ is to limit testing on Rubinius 2.x since there will be other versions of Rubinius > 2.x soon. This part is unrelated to loading gems.
I’ve changed Rubinius code loading to avoid Bundler stripping pre-installed gems. I’ll be making a patch to Bundler so it will specifically consider pre-installed gems but in any case, Bundler will no longer prevent eg rubysl-securerandom or whatever from being loaded. I’m writing a Migrating from MRI guide that will cover this.
The now-recommended part of .travis.yml
rvm:
- rbx-2
Original Fix:
- Update travis.yml to specify
rbx
wherever you hadrbx-whatever
- Add a special travis gemfile or modify your gemfile to have some subset of
platforms :rbx do
gem 'psych' # if using yaml
gem 'rubysl', '~> 2.0' # if using anything in the ruby standard library (meta-gem)
gem 'minitest' # if using minitest
gem 'rubysl-test-unit' # if using test-unit with minitest 5.x https://github.com/rubysl/rubysl-test-unit/issues/1
gem 'racc' # if using gems like ruby_parser or parser
gem 'rubinius', '~> 2.0' # if using any of rubinius-developer_tools and/or rubinius-build_tools
gem 'rubinius-build_tools' # if using any ast parsing, processing, or building
gem 'rubinius-developer_tools' # if using any of coverage, debugger, profiler
end
Selected parts of my .travis.yml
language: ruby
gemfile:
- gemfiles/Gemfile.travis
rvm:
- 2.0.0
- 1.9.3
- jruby-19mode # JRuby in 1.9 mode
- rbx
matrix:
allow_failures:
- rvm: rbx
cache: bundler
Notice the cache: bundler
line?
Since there are a lot of rubysl downloads, you can get a significant speed-up by telling Travis to cache them.
Selected parts of my Gemfile.travis
source 'https://rubygems.org'
# to use, from the app root run
# export BUNDLE_GEMFILE=$PWD/gemfiles/Gemfile.travis
# when done, unset BUNDLE_GEMFILE
platforms :rbx do
gem 'racc'
gem 'rubysl', '~> 2.0'
gem 'psych'
end
eval_gemfile File.expand_path('../../Gemfile', __FILE__)
For completeness, the working commands that now run on travis are
rvm use rbx --install --binary --fuzzy
# rubinius 2.2.1 (2.1.0 3ed43137 2013-11-17 JI) [x86_64-linux-gnu]
rvm --version
# rvm 1.24.5 (latest-minor) by Wayne E. Seguin <wayneeseguin@gmail.com>, Michal Papis <mpapis@gmail.com> [https://rvm.io/]
Examples of rbx-specific Gemfile entries:
-
I’m submitting a patch to Bundler after discussing with Andre that will enable Rubinius to designate rubysl as gems that are bundled with the distribution and Bundler will use that information while resolving.
This patch is a stop-gap measure and I can submit another PR to remove this once Bundler with that patch is released.
platforms :rbx do
gem 'rubysl', '~> 2.0'
gem 'rubinius', '~> 2.0'
end
platform :rbx do
gem "rubysl-rake", "~> 2.0"
gem "rubysl-bundler", "~> 2.0"
gem "rubysl-digest", "~> 2.0"
end
- require 'test/unit/assertions'
+ begin
+ require 'test/unit/assertions'
+ rescue LoadError
+ # work around for Rubinius not having a std std-lib
+ require 'rubysl-test-unit' if defined?(RUBY_ENGINE) && RUBY_ENGINE == 'rbx'
+ require 'test/unit/assertions'
+ end
References:
- Twitter conversation about the failures
- It appears part of the issue is whether or not the gem spec PLATFORM can/should/does refer to RUBY_ENGINE
- Rubinius Post: Testing Your Project with Rubinius on Travis
- Rubinius meta-gems: rubinius.gemspec, rubinius-developer_tools, rubinius-build_tools, ruby-sl, rubysl-rake, rubysl-bundler, rubysl-rspec
Original content source: my comment on travis-ci issue
blog comments powered by Disqus