I'd like to test my Vagrant plugin against multiple versions, using for each release the same ruby version embedded with the Vagrant package. I've created the following configuration file for Travis CI:
language: ruby
matrix:
include:
- rvm: 1.8.7-p357
gemfile: gemfiles/vagrant1_1.gemfile
- rvm: 1.9.3-p448
gemfile: gemfiles/vagrant1_2.gemfile
gemfile: gemfiles/vagrant1_3.gemfile
- rvm: 2.0.0-p353
gemfile: Gemfile
But when I try to validate this configuration against the Travis Lint web service I receive the following error:
Found an issue with the rvm key:
Specify Ruby versions/implementations you want to test against using the "rvm" key
First experience with Travis CI, I can't understand what I'm doing wrong.
Travis seems to require that you specify at least one default rvm. Like:
language: ruby
rvm: 2.0.0
matrix:
# ...
Other issue is that I'm quite sure the second gemfile in '1.9.3-p448' will just override the first one.
And third, Vagrant officially supports only one Ruby version. Before 1.4 Vagrant only works with Ruby 1.9.3, from 1.4 on with Ruby 2.0.0. You might not hit problems in plugin's unit tests, but no need to consume Travis resources. =)
For env var based approach (instead of Gemfile based), see vagrant-proxyconf's .travis.yml and Gemfile.
Related
I am using rbenv and bundler on macos.
I need to maintain multiple versions of Ruby for my application. Specifically 2.2.4 and 2.5.5. Different users will have different versions.
Currently I am only working with 2.2.4 so I do the following. My gemfile looks like this
source "https://rubygems.org"
ruby '2.2.4'
gem "net-ssh", "4.1.0"
gem "net-scp", "2.0.0"
.....
To install I run bundle install and then to deploy with my application I run
bundle install --deployment --path src/mct-tools/ext/gems
This generates a folder src/mct-tools/ext/gems/ruby/2.2.0 in my application that I then distribute.
Now I would like to add ruby 2.5.5 with updated gems so I was wondering whether it would be acceptable to have a gemfile looking like this one
source "https://rubygems.org"
ruby '2.2.4'
gem "net-ssh", "4.1.0"
gem "net-scp", "2.0.0"
.....
ruby '2.5.5'
gem "net-ssh", "6.1.0"
gem "net-scp", "3.0.0"
.....
so that when I deploy with bundle install --deployment --path src/mct-tools/ext/gems the two versions are added to the gems folder.
Is this the correct approach? An alternative would be to specify two different gemfiles for each version and then switch between them.
Gemfiles Declare Dependencies
A Gemfile declares a dependency on a Ruby version, with or without semantic versioning constraints. It is not meant to control multiple build targets for your application. It simply enforces that the Ruby version available to your app/gem is whatever you've defined. For example:
# Will fail if run with a different RUBY_VERSION.
ruby '2.2.4'
# Allows RUBY_VERSION >= 2.2.4, but <= 2.3.
ruby '~> 2.2.4'
# Allows either Ruby 2.2.4+ or 2.5.5+, with
# a minimum (but no maximum) patch version.
ruby '~> 2.2.4', '~> 2.5.5'
However, it won't install a given Ruby, nor do anything other than raise an error and a non-zero exit status when running bundler install. You need to take a different approach to test multiple targets.
Changing Build Targets with Continuous Integration (CI) Tools
If you're using an external CI like TravisCI, you can create a build matrix that targets multiple Ruby versions to test against. Whether you remove the Ruby version constraint altogether, or specify a supported range, is up to you. Leveraging your CI tool to build against the versions of Ruby you plan to support is really the best approach, though, whether or not you constrain your Ruby runtime in a Gemfile.
For example, you might use a matrix in your travis.yml like so:
language: ruby
rvm:
- 2.2.4
- 2.5.5
Switching Gemfiles
If you insist on doing it the way you're doing it, with a singular Ruby version allowed in your Gemfile, then you might consider having two separate gemfiles with different names in your source tree, such as Gemfile-2.2.4 and Gemfile-2.5.5. You can then specify which Gemfile to use with Bundler's --gemfile flag , or by symlinking a custom Gemfile to the canonical Gemfile for your project.
Here are some examples to consider:
# Resolve against a specific Gemfile with
# hard-coded Ruby version.
$ ls Gemfile*
Gemfile-2.2.4 Gemfile-2.5.5
$ bundle install --gemfile="Gemfile-2.2.4"
# Resolve against whatever custom file is
# symlinked to your ./Gemfile.
$ ln -sf Gemfile{-2.5.5,}
$ ls -F Gemfile*
Gemfile# Gemfile-2.2.4 Gemfile-2.5.5
$ bundle install
Both approaches work, but the former is more flexible at the cost of needing to specify your chosen Gemfile each time, while the latter can help when you have a development/testing workflow that doesn't support Bundler's --gemfile flag.
Changing Rubies with Ruby Managers
If you have multiple Ruby versions in development, best practice is to use a version manager such as rvm, rbenv, or chruby. You can use your version manager to change rubies back and forth manually as needed.
You might also check whether your version manager supports auto-switching on .ruby-version or other configuration files. You'd still have to update that file each time you want to build or test against a different Ruby, but you wouldn't have to keep changing your Gemfile contents, re-pointing the Gemfile symlink, or updating a flag on each call to Bundler.
Whether or not any given approach is better than others will depend on your workflow. No technical solution will fit all circumstances, so your mileage may legitimately vary.
I started learn Ruby (for automation tests) in Rubymine but I have a problem with gems.
I downloaded some projects from github but I am not able to run projects Same with some tutorials.
Now as i understand:
EVERY project should have GEM FILE with gem versions.
It is possible to have projects with different version
bundles should take care of gems (but i have the problem with this)
My version ruby :2 .2.4
cucumber 2.2.4 gem 2.4.5.1
Do you recommend RVM? How can I correct install this(I downloaded something for key and sing up but no email with password) I could not use also curl command
I tried using : https://rvm.io/rvm/install
I am using RubyMine(for 30days so soon will finish:(() I used e.g https://github.com/RailsApps/rails-bootstrap
and here I have:
alidate_ruby!': Your Ruby version is 2.2.4, but your Gemfile specified 2.2.3 (Bundler::RubyVersionMismatch)
Can anybody help me? Thanks!
I'm having an intermittent issue where my Jekyll site fails to build due to a gem installer error:
Gem::InstallError: public_suffix requires Ruby version >= 2.0.
My understanding is that Pages runs Ruby 2.x, but Travis shows v1.9.3 during the failed build.
I haven't built the site locally - just forked a repo, bumped a few files via prose.io, and the build fails. I had the same issue a couple of days ago on committing a new post, but it seemed to resolve itself.
Any suggestions as to how to correct this?
Per this issue (the very first result when I googled your error message), you need to explicitly specify your Ruby version in .travis.yml:
The current TravisCI default Ruby 1.9.3 is now too old for the pages gem (see http://docs.travis-ci.com/user/languages/ruby/#Supported-Ruby-Versions), so we should ask TravisCI to use Ruby 2.1.1 to match what is currently used on GitHub pages (https://pages.github.com/versions/).
i.e. your .travis.yml should include:
language: ruby
rvm: 2.1.1
script: "bundle exec jekyll build"
Hy guys,
I have a server with apache, passenger 4.0.50, ruby 2.1.2 (started with 1.9.3), RVM and dozen of ruby on rails 4.1.x apps.
RVM is used only to manage ruby versions.
Follows the bundler configuration for each app:
BUNDLE_FROZEN: '1'
BUNDLE_PATH: "/PATH/TO/DEPLOYED/APP/shared/bundle"
BUNDLE_WITHOUT: development:test
BUNDLE_DISABLE_SHARED_GEMS: '1'
In order to save disk space (a lot of space) I would like to remove old gems of each application using bundle clean
The idea is to keep 2 releases (capistrano) and to run the command before a new deploy in order to keep gems for the last release.
The problem is that gems installed whit ruby 1.9.3 are not removed.
Can you please confirm that:
Gems for ruby 2.1.2 are installed in /PATH/TO/DEPLOYED/APP/shared/bundle/ruby/2.1.0/gems
Gems for ruby 1.9.3 are installed in /PATH/TO/DEPLOYED/APP/shared/bundle/ruby/1.9.1/gems
I can remove directory /PATH/TO/DEPLOYED/APP/shared/bundle/ruby/1.9.1/gems since I'm not using ruby 1.9 anymore
Many thanks in advance for your help.
Mauro
You dont use ruby 1.9.x anymore, so just remove the gems directory for it.
I have a box with 3 Rails apps on it. I wan't to upgrade one of the apps so that it uses Ruby 2.0.0, while leaving the others running on 1.9.3-p394. I have both those Rubies installed via Rvm.
I'm trying to control the Ruby version that each app uses via it's Gemfile.
# Gemfile
ruby '2.0.0'
So, I changed the version number in the Gemfile locally, made sure it all worked, committed and now I'm trying to deploy the change to the server.
However, the cap deploy fails at this point
bundle install --gemfile [path to release Gemfile] --path [path to app bundle] --deployment --quiet --without development test
because
Your Ruby version is 1.9.3, but your Gemfile specified 2.0.0
This is correct technically, my Gemfile does specify 2.0.0 and the app is currently running on 1.9.3. I'm trying to make it change versions before bundling though. How do I do that?
Your PATH is not set up correctly. You probably don't have bin: as the first entry in your path. That would lead to this error.
Even if you're not using Heroku it's worth reading this page on troubleshooting that issue: https://devcenter.heroku.com/articles/ruby-versions
Here is a link to an answer which will explain how to change your PATH on the server: Capistrano: Can I set an environment variable for the whole cap session?
If you have rvm maybe you can try to do
rvm use 2.0.0
before your bundler call.
If you're using rvm set the default to ruby 2.0.0 on your server
rvm --default use 2.0.0
Resolved the problem for me deploying to an AWS server from my mac - but I guess if I need to update my older sites I'll have to set the default back to 1.9.3 before deploying.