In the above scenario if someone with Ruby 2.3.1 on their system runs bundle install then they will get this in the Gemfile.lock: RUBY VERSION For example neither ~> 2.3 or ~> 2.3.x are valid version specifiers on Heroku.īundler locks your Ruby version you are using locally in the Gemfile.lock. For this to work on Heroku, you must specify the full version with all three digits. This is saying that any version of 2.3.x where x is greater than or equal to 0 are valid. For example if you want to deploy using 2.3.0 but some members of your team want to use 2.3.1 you could allow this by specifying: ruby "~> 2.3.0" Ruby Version SpecifiersĪs of bundler 1.12+ you can use a version specifier in your Ruby version. Please see Ruby Support for a list of available versions. You can specify JRuby by using the following line: ruby "2.2.2", :engine => "jruby", :engine_version => "9.0.0.0" > Installing dependencies using Bundler version 1.7.11įor specifying non MRI Ruby engines, you’ll need to use the :engine and :engine_version options. When you commit and push to Heroku you’ll see that Ruby 2.5.1 is detected: -> Heroku receiving push For an updated list see Supported Ruby Versions. Ruby 2.5.1 might not be the latest Ruby version, and is here for demonstration purposes only. ![]() The fix is same, add the platform to Gemfile.lock and redeploy.Heroku recommends you run the latest Ruby version your app can handle. It can be seen in any other deployment platform as well where we are deploying to Linux and developing on Mac. This is not specific to deployments on Heroku only. diff -git a/Gemfile.lock b/Gemfile.lockĪfter pushing this change to Heroku, the deployment went through. This generated following diff in Gemfile.lock. To fix this, as the warning recommended, I added linux platform using following command. Though you should not do this as dev-prod parity breaks down and in production, bundler may resolve to the gems which you have not tested in development or test mode. If we do not use the deployment mode, then bundler will resolve the gems in real time with current platform and this problem will not happen. ![]() In our case, the Gemfile.lock is not compatible with the platform on which Heroku is deploying which is Linux and the platform on which it was generated which is Mac. It expects that Gemfile.lock to be frozen and already compatible with the platform on which it is being run. When deploying to Heroku, the Heroku Ruby buildpack runs bundle install in deployment mode. To mitigate such errors, bundler now sets up Gemfile.lock for the platform on which it was generated. In previous versions of Bundler, the approach for detecting the platform specific version was error-prone as per this comment. Kudos to Heroku buildpack to raise a user friendly error message!Ī lot of gems such as nokogiri ship platform specific releases. PLATFORMSĪs per the warning it seems that my Gemfile was generated for Mac OS X but I am deploying to Linux and it was raising a flag. The Gemfile.lock contained following line. It only happens with Bundler 2.2.3 and above. ! Push failed If you are using Bundler 1.x you will not run into this error. ![]() ! Push rejected, failed to compile Ruby app. ![]() add-platform x86_64-linux` and try again.īundler Output: Your bundle only supports platforms but your local platform Add the current platform to the lockfile with `bundle lock Your bundle only supports platforms but your local platform Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 bundle install -j4 > Installing dependencies using bundler 2.2.15 > Removing BUNDLED WITH version in the Gemfile.lock While deploying a new Rails 6.1.3.1 application built with Bundler 2.2.16 on Heroku, I ran into this error in Heroku build log.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |