In Heroku:
Gemfile.lock ensures that your deployed versions of gems on Heroku
match the version installed locally on your development machine
Is it the same with Elastic Beanstalk?
Elastic beanstalk uses bundler so if you have a Gemfile.lock it will be respected. You could also package dependencies along with your app using bundle package.
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've followed the "minimal AWS deployment" guide here https://github.com/cloudfoundry/cf-release/tree/master/example_manifests to try CloudFoundry.
I understand that I have to install the bosh_cli_plugin_micro, but when I run this on an AWS Ubuntu 14.04 VM:
gem install bosh_cli_plugin_micro
I get:
ERROR: While executing gem ... (Gem::DependencyError)
Unable to resolve dependencies: blobstore_client requires aws-sdk-resources (= 2.2.0); aws-sdk requires aws-sdk-v1 (= 1.60.2)
Installing the AWS ruby sdk doesn't solve the problem. I suspect it's a problem of the aws sdk being a newer version than the one the micro bosh cli expects. Anyone have any suggestions?
One way to ensure you get a consistent set of gems would be to create a Gemfile like this:
source 'https://rubygems.org'
gem 'bosh_cli'
gem 'bosh_cli_plugin_micro'
and then run the bundle command from the same working directory as where your Gemfile is placed. To make sure you're always using the right version of the CLI and plugin, prepend commands with bundle exec, e.g.
$ bundle exec bosh micro deploy /path/to/stemcell
You may even wish to alias bosh to bundle exec bosh.
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.
Can not update gems on production server.
I've tried bundle install --deployment and bundle install --without development test
But keep getting:
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
If this is a development machine, remove the Gemfile freeze
by running `bundle install --no-deployment
EDIT
I don't know if this is correct, but needed a quick fix. I ran bundle install --no-deployment then bundle update then ran bundle install --deployment again
The instructions are probably a bit confusing. It's saying that you've modified your Gemfile on your development machine and just pushed those changes rather than running bundle install BEFORE committing the changes.
By running bundle install you will update your Gemfile.lock file. This should be pushed to your server as it's more important than Gemfile. Consider the Gemfile the plans for the Gemfile.lock file.
Always remember to:
Run bundle install if you change your Gemfile, even just to make sure. If it's too slow, pass --local through which forces it to only use local gems to resolve its dependencies.
Commit both the Gemfile and Gemfile.lock file to your repository
Deploy both the Gemfile and Gemfile.lock to your production servers to ensure that they're running the exact same dependencies as your development environment.
Running bundle update by itself can be construed as dangerous that will update all the dependencies of your application. It's mainly dangerous if you don't have solid version numbers specified in the Gemfile. I wrote about it here.
FWIW I had this problem and fixed it by removing some conditional statements from my Gemfile (conditionals on OS) and rerunning bundle.
FYI: You can also get this error if you use source blocks like this:
source 'https://rails-assets.org' do
gem 'rails-assets-jquery'
end
You'll see an exclamation point in the Gemfile.lock for this gem:
rails-assets-jquery!
Just define the additional source normally, i.e.
source 'https://rails-assets.org'
gem 'rails-assets-jquery'
(BTW cf. here about using multiple gem sources.)
This can be caused by an old version of the bundler gem on the server you're deploying to (in this case production). Logging into the server and running a gem update bundler resolved the issue for me. The server I was deploying to was running version 1.7.4 and the current version was 1.9.
I had an issue with my production server still using an old version of a gem, even though the Gemfile.lock showed the correct, updated version. My production server was running on Unicorn - and shutting down / starting it back up again fixed the issue - instead of sending the HUP signal, which did jack all to fix the issue.
bundle install failed on my "development" machine because of the mysql-gem on osx...
I also needed a quick fix. So I cloned the repo to a new folder on the production machine, ran "bundle install" there and committed the Gemfile.lock to the repo.
I have had this problem (Ubuntu 12.10 & 12.04, one of which behind a proxy server).
My problem was that I had some git:// protocols in the Gemfile. Changing this to http:// helped me get it all working.
I am currently running a gem server for our company that stores our local in house gems. We are currently using the default rubygems server that is invoked with gem server. However whenever we fetch from this server (using bundler) we get:
Could not fetch prerelease specs from rubygems repository http://rubygems.myserver.org
The server works fine otherwise, but we would actually like to have our server support prerelease anyhow. Is anyone running a gem server successfully with prerelease? If so what server are you using and how? I cannot seem to find any documentation on this.
The solution to this is not to use gem server, but use a regular web server then execute gem generate_index. This successfully built prerelease and regular indexes.
http://docs.rubygems.org/read/chapter/18 section 4.2