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"
Related
So I've been building a blog site using Jekyll and an specific theme called Chirpy, and deploying it all using Cloudflare Pages, the code is stored in a private Github repository so anytime I push code a new build gets generated by Cloudflare automatically.
It's been working fine for months but after some updates deploying a new build fails as:
12:57:58.188 Success: Finished cloning repository files
12:57:58.890 Installing dependencies
12:57:58.901 Python version set to 2.7
12:58:03.233 v12.18.0 is already installed.
12:58:04.608 Now using node v12.18.0 (npm v6.14.4)
12:58:04.922 Started restoring cached build plugins
12:58:04.937 Finished restoring cached build plugins
12:58:05.597 Attempting ruby version 2.7.1, read from environment
12:58:09.668 Using ruby version 2.7.1
12:58:10.041 Using PHP version 5.6
12:58:10.042 Started restoring cached ruby gems
12:58:10.060 Finished restoring cached ruby gems
12:58:10.062 Installing gem bundle
12:58:10.368 [DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set path '/opt/buildhome/cache/bundle'`, and stop using this flag
12:58:10.526 [DEPRECATED] The --binstubs option will be removed in favor of `bundle binstubs`
12:58:13.673 Fetching gem metadata from https://rubygems.org/..........
12:58:13.834 Fetching gem metadata from https://rubygems.org/.
12:58:13.935 Resolving dependencies...
12:58:14.019 sass-embedded-1.58.0-x86_64-linux-musl requires rubygems version >= 3.3.22,
12:58:14.019 which is incompatible with the current version, 3.1.2
12:58:14.052 Error during gem install
12:58:14.073 Failed: build command exited with code: 1
12:58:14.848 Failed: an internal error occurred
Now Cloudflare allows you to specify which command you want to use in order to execute the build, that being:
bundle exec jekyll b
I've been looking for a way to update the Ruby version being used in Cloudflare and could not find any resources more than this one post. I've tried changing the Gemfile like:
spec.required_ruby_version = ">= 3.0"
, but it seems like Cloudflare does not support Ruby 3 at all; I then had the idea to use an older version of the Chirpy theme, since I already have a deployed version of the blog, I went back to Chirpy 5.2.1 but surprisingly the error persist.
Definitely adding gem "jekyll-sass-converter", "~> 2.0" to the Gemfile solved this problem, as Christian mentioned.
I'm trying to publish an article to my blog on GitHub pages after a few months of absence, and am getting the following error:
Gem::InstallError: public_suffix requires Ruby version >= 2.0.
Installing sass 3.4.20
An error occurred while installing public_suffix (1.5.2), and Bundler cannot
continue.
Make sure that gem install public_suffix -v '1.5.2' succeeds before bundling.
However according to GitHub the Ruby version on GH pages is already > 2.0. Is there some programmatic change that I need to make in my blog's codebase to get this up and running?
This is the corresponding Gemfile:
source 'https://rubygems.org'
# A simple Ruby Gem to bootstrap dependencies for setting up and
# maintaining a local Jekyll environment in sync with GitHub Pages
# https://github.com/github/pages-gem
gem 'github-pages'
Try deleting your gemfile.lock and pull down the last working gemfile.lock file from your GitHub pages repo. (or just checkout the file from an earlier, working commit)
Most of the weird errors stem from the errors with the Gemfile.lock file, which is used to keep track of the versions of each Ruby Gem. Sometimes when running bundle update gems are attempted to be upgraded, which may break compatibility with other gems, at least that's what has happened to me before. Often times running bundle update causes some gems to be downgraded. As a temporary workaround to just get Jekyll to build locally, just revert the file to an earlier version.
While trying to install Capistrano, I got an error message that rake was not available. since rake is included with ruby, what do I need to do?
Loading files require extra working memory. Cutting off some features and loading them only when necessary with explicit load command will save memory.
Simple mistake, but I will post the answer in case anyone else has had the same frustration - the version of Ruby I was using, 1.9.3, has a 9.x version of Rake bundled with the Ruby installation; Capistrano 3 requires a 10.x version. I installed Rake 10.4.2; problem solved.
Note: If you install a 2.1.x or later version of Ruby, you will automatically get a 10.x version of Rake.
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.
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.