Build-image: "Trusty" Build image does not appear to respect bundler version in Gemfile.lock

[SeanKilleen]

I have been using Netlify for previews of my Jekyll blog, along with Netlify Admin CMS (I absolutely love Netlify -- thank you!)

Codebase here: http://github.com/SeanKilleen/seankilleen.github.io

Recently, I updated some dependencies and needed to bump my Ruby & bundler versions, which appears to fail the build, which is unexpected given the other docs I've read.

Recreation steps:

• Utilize version 2.6.2 of Ruby.
• Specify the version in a .ruby-version file
• Create a Gemfile.lock using bundler 2.1.4.
• Verify that the lock file includes:

BUNDLED WITH
   2.1.4

• Trigger a Netlify build.

Expected Behavior

• Build uses Ruby 2.6.2
• Build uses Bundler 2.14 specified in Gemfile.lock
• Build succeeds.

Actual Behavior

✅ Build uses ruby 2.6.2
❌ Build does not use bundler 2.14, but rather appears to use 2.0.1 (output reads Using bundler 2.0.1)
❌ Build does not succeed, but fails with the below error when invoking the Jekyll build process:

12:51:17 PM: Activating bundler (2.1.4) failed:
12:51:17 PM: Could not find 'bundler' (2.1.4) required by your /opt/build/repo/Gemfile.lock.
12:51:17 PM: To update to the latest version installed on your system, run `bundle update --bundler`.
12:51:17 PM: To install the missing version, run `gem install bundler:2.1.4`
12:51:17 PM: Checked in 'GEM_PATH=/opt/buildhome/.rvm/gems/ruby-2.6.2:/opt/buildhome/.rvm/rubies/ruby-2.6.2/lib/ruby/gems/2.6.0', execute `gem env` for more information
12:51:17 PM: To install the version of bundler this project requires, run `gem install bundler -v '2.1.4'`

Am I missing something that explicitly sets the Bundler version? Want to rule out anything I might be doing, but AFAIK this build is a pretty basic/straightforward Jekyll build.

[SeanKilleen]

in case it helps: I copied https://github.com/netlify/build-image/blob/xenial/run-build-functions.sh#L301 and ran it locally to ensure it would return 2.1.4, and it does.

[SeanKilleen]

More info --

Despite the code at https://github.com/netlify/build-image/blob/xenial/run-build-functions.sh#L302-L307, I do not see the expected text, "Using bundler version $bundler_version from Gemfile.lock" in the output.

So, I'm not sure if the build script is not finding my Gemfile.lock for some reason (this build worked previously for a long time until I started specifying versions), or if something else unexpected is happening.

I think this would be much faster to diagnose with some additional output; going to propose some more in a PR now.

[SeanKilleen]

This appears related to https://github.com/netlify/build-image/issues/296. The bundled with version is 2.1.4 but the build logs indicate 2.0.1

[SeanKilleen]

Workaround: removing my Gemfile.lock allows this to work, because there's now no reference to Bundler 2.1.4.

However, it means that my lockfile is now not the same between my own environments and with Netlify.

[joshqn]

I'm experiencing the same issue. When I removed the "BUNDLED WITH" from the Gemfile.lock and deploy that it works. The bundle version used instead on my local 2.1.4 version is 2.0.1 on the Netlify server.

[jglovier]

I have the same issue, and found a workaround by downgrading my local bundler to 2.0.1 and generating a new lockfile. I then also had to add

before_install:
  - gem install -v 2.0.1 bundler

to my .travis.yml file to get it to pass Travis with my Gemfile.lock generated by an older version of Bundler.

Wheeeeeee!!!

[jglovier]

Update: I ran across a similar thread on the Netlify community site, which referenced this article about an updated build image, and flipped it on for my Netlify site, reverted all these crazy changes, and it just works now!! Yay!

[SeanKilleen]

@jglovier I'd missed this comment back in December but just tried it and it works excellently! Thank you!

[smithtimmytim]

@jglovier thank you for saving me so much time today!

[jglovier]

@SeanKilleen @smithtimmytim glad it was helpful! ✨🙌✨

[SeanKilleen]

Given @jglovier's solution above, going to go ahead and close this issue.