rvm: 2.4 installation fails #7077
Comments
|
Do you have a build log URL that shows the problem you are describing here? |
|
Please try |
|
But that wont automatically update when 2.4.1, etc are released, like |
|
I don't think |
|
In other words, MAJOR.MINOR is an alias defined for the runtimes pre-installed on the build image. As such, |
|
Ah thanks, I thought it worked the same way as |
... and possibly Ruby 2.3 travis-ci/travis-ci#7077
* Update to ruby 2.4 final + enable 2.3 latest See travis-ci/travis-ci#7077
Refer travis-ci/travis-ci#7077 for the issue.
|
It would be awesome if there were some way to tell travis "use the latest 2.4.x". |
|
Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues |
Builds on Travis were failing, returning an error "Could not find 'bundler' (1.16.2) required by your Gemfile.lock". It seems this problem was caused by a forced upgrade of Ruby Gems, which, in turn, was caused because our Travis RVM config forces an old version of Ruby (2.3.3) which is not supported by the Travis build environment (see https://travis-ci.org/sul-cidr/noh/builds/629005327, esp. the `rvm use 2.3.3 --install --binary --fuzzy` command at line 176 and the `ruby --version` command at line 207). The CI environment has Ruby 2.3.8 pre-installed, and switching the RVM config to use this version enables the use of the pre-installed `bundle` executable. This allows builds to complete, and has the pleasant side-effect of speeding up the build-time considerably, too (see https://travis-ci.org/sul-cidr/noh/builds/629162946 -- I ran a manual build on Travis with a custom config). It seems that RVM has no `2.3.x` syntax, or equivalent (see rvm/rvm#3512), which is disappointing. However, it seems Travis does have functionality whereby specifying a `MAJOR.MINOR` without a `.PATCH` causes the build environment to use its pre-installed binaries for that version (see travis-ci/travis-ci#7077 and https://docs.travis-ci.com/user/languages/ruby/#specifying-ruby-versions-and-implementations). This has the advantage of avoiding the problem encountered today, when Travis updates its build images, but presumably means that builds will fail if/when Ruby 2.3 is removed from those images. On balance, this seems the lesser evil, so this commit sets the Travis RVM config to `2.3`. Committing directly to `contents` in the interest of expediency.
According to travis-ci/travis-ci#7077 MAJOR.MINOR is an alias defined for the runtimes pre-installed on the build image. As such, 2.4 will not work until a version of 2.4.x is pre-installed. This will come in time, but until then, .0 is necessary. I don't think 2.1 or 2.2 work that way, either. For example, 2.2 points to 2.2.5 at the moment, though the latest version is 2.2.6. Similarly for 2.1. So it seems best to specify the minor (minor) version. Note: ruby 2.1.10 is out but not available on travis according to http://rubies.travis-ci.org/ But according to the travis of bundler it still seems to work https://travis-ci.org/bundler/bundler/
* Update to ruby 2.4 final + enable 2.3 latest See travis-ci/travis-ci#7077
Ruby 2.4 was released within the past few hours, this probably necessitates updating RVM?
The text was updated successfully, but these errors were encountered: