Update Gemfile.lock for vendored Gemfiles
What does this MR do and why?
- Runs
rm Gemfile.lock && BUNDLE_FORCE_RUBY_PLATFORM=1 bundle installfor vendored gems which have a PLATFORM other than 'ruby', then reverts all other unnecessary version bumps inGemfile.lock.- Fixed
attr_encryptedandbundler-checksumGemfile.lockfiles - Adds missing
Gemfile.locklockfile foromniauth-google-oauth2
- Fixed
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:
- If there is no existing
Gemfile.lockand arubyplatform 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. - But, once the
Gemfile.lockis created, a normalbundle installWILL use a platform-specific gem if it is already installed. - 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.
-
I have evaluated the MR acceptance checklist for this MR.