Make dependencies consistent

[alexeyr-ci1]

• [ ] /Gemfile.lock is currently ignored. This used to be the recommendation, but the current Bundler docs disagree:

  Q: Should I commit my Gemfile.lock when writing a gem?

  A: Yes, you should commit it. The presence of a Gemfile.lock in a gem's repository ensures that a fresh checkout of the repository uses the exact same set of dependencies every time. We believe this makes repositories more friendly towards new and existing contributors. Ideally, anyone should be able to clone the repo, run bundle install, and have passing tests. If you don't check in your Gemfile.lock, new contributors can get different versions of your dependencies, and run into failing tests that they don't know how to fix.

  Q: But I have read that gems should not check in the Gemfile.lock!

  A: The main advantage of not checking in your Gemfile.lock is that new checkouts (including CI) will immediately have failing tests if one of your dependencies changes in a breaking way. Instead of forcing every fresh checkout (and possible new contributor) to encounter broken builds, the Bundler team recommends either using a tool like Dependabotto automatically create a PR and run the test suite any time your dependencies release new versions. If you don't want to use a dependency monitoring bot, we suggest creating an additional daily CI build that deletes the Gemfile.lock before running bundle install. That way you, and others monitoring your CI status, will be the first to know about any failures from dependency changes.

• [ ] When it's checked in, it seems we should ensure the versions there and in spec/dummy/Gemfile.lock are the same. I ended up with a mismatch in rdoc and rspec versions, and it lead to problems (don't have the specific message at hand anymore).

• [ ] We can also add a CI check to make sure they remain in sync in the future.

• [ ] (optional) Add Dependabot as advised by Bundler.

[jasonfb]

• Don't ignore the Gemfile.lock in the repository, instead omit both the Gemfile and the Gemfile.lock from the files that are bundled when you build the gemcode. This is set in the gemspec here

https://github.com/shakacode/react_on_rails/blob/master/react_on_rails.gemspec#L19

I think adding Gemfile|Gemfile.lock to that exclude list is what you want

• I too have the same problem with keeping the Gemfile consistent with Gemfile in my Dummy app. I noticed that CircleCI seems to not reload the gems when switching into the Dummy app, but Github CI does.

So the Gemfile in the root of the repo should ideally only be what is necessariy to bootstrap the tests, and then you can switch into the dummy app and load Rails from the dummy app, using the Dummy's gems. (like I said, I got this working on Github CI but not working on Circle CI so this is tricky)

Short of that, a sync solution sounds like a good plan B

[Judahmeek]

@justin808 @alexeyr-ci1

Whether Gemfile.lock is gitignored or not isn't really relevant.

If you run into a situation where the Gemfile.lock are desynced on CI & that's causing an actual problem, then break the CI gem caches & add bundle update to the workflow for both root & spec/dummy gemfiles.

I think that any desync being serious enough to cause a problem should be rare enough that enforcing sync between the Gemfile.locks should be unnecessary.