Update Gemfile.lock for vendored Gemfiles

What does this MR do and why?

  • Runs rm Gemfile.lock && BUNDLE_FORCE_RUBY_PLATFORM=1 bundle install for vendored gems which have a PLATFORM other than 'ruby', then reverts all other unnecessary version bumps in Gemfile.lock.
    • Fixed attr_encrypted and bundler-checksum Gemfile.lock files
    • Adds missing Gemfile.lock lockfile for omniauth-google-oauth2

This is necessary to prevent a dirty repo from occurring when RubyMine auto-bundles for all Gemfiles found in the monorepo repository, which is the default behavior for RubyMine.

Without this fix, RubyMine users must manually discard the changes to these lockfiles after every git pull, rebase, or IDE restart.

See also this comment about the deprecation of the ruby platform (https://github.com/rubygems/rubygems/issues/3379#issuecomment-1196299629), but we are still using it in order to avoid having to manually bundle on all supported platforms.

The way that BUNDLE_FORCE_RUBY_PLATFORM=1 bundle install works is that:

  1. If there is no existing Gemfile.lock and a ruby platform gem is NOT currently installed, then it will force installation and compilation of the gem from source, EVEN IF a platform-specific gem is already installed.
  2. But, once the Gemfile.lock is created, a normal bundle install WILL use a platform-specific gem if it is already installed.
  3. It's important to remember that with this approach, since it requires deleting and recreating Gemfile.lock, you should ensure that you revert any gem semantic version changes that not just a platform change, because they could potentially cause regressions due to the newer version being used.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Chad Woolley

Merge request reports

Loading