dependabot
Update Rubygems to 3.5.21 and Bundler to 2.5.21
What are you trying to accomplish?
This Bundler update contains some changes to how Git dependencies are vendored, which would be good to get into Dependabot
How will you know you've accomplished your goal?
Passes the test suite.
Checklist
- [ ] I have run the complete test suite to ensure all tests and linters pass.
- [ ] I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
- [x] I have written clear and descriptive commit messages.
- [x] I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
- [x] I have ensured that the code is well-documented and easy to understand.
The test cases are failing
@honeyankit I'd made a typo in the Dockerfile which is why, should be good now, but let's wait for tests to complete and see if the update broke anything, it's faster to have CI run them than to do it locally.
The failing test is new (desired) behavior in Bundler that should be backwards compatible, and the test can be updated, I'll take care of that
Hmm actually appears the change is not backwards compatible, this means that:
Customers on older versions of bundler using vendoring with git dependencies would not be able to use caches of git dependencies generated by Dependabot
I'm going to pull some data to figure out if we can live with it, it should be relatively easy for those folks to upgrade to the latest version of Bundler to mitigate it, so trying to get a feel for how many customers we're talking about here
Hello! 👋
Yes, this change is backwards compatible in the sense that newer Bundler won't just crash if it finds an old cache, but will migrate it to the new format. But it does not keep generating the old format, so in that sense it's not backwards compatible, and once migrated it will not work with older Bundler versions.
Before, Bundler would simply clone the repo to vendor/cache, but would never actually install it to vendor/bundle or to whatever the configured installed path is. It would instead directly use the version from vendor/cache. This is not correct because, for example, gems with extensions never got actually compiled.
Because we considered the old way broken, we considered this change a bug fix, and didn't keep supporting the old format at all.
Thanks @deivid-rodriguez, I have some numbers on the number of repos that have vendoring configured for bundler and it's not huge, will try to get a few more numbers and check in maybe with @jonjanego, but given that upgrading should be easy for those customers anyway, and the old behavior is considered a bug, maybe we can move forward without complicating things
Personally I would favor keeping bundler up to date over this niche functionality breaking on older versions
Thanks @deivid-rodriguez, I have some numbers on the number of repos that have vendoring configured for bundler and it's not huge
Note that this not only vendoring, but vendoring + using git gems. I assume it's something quite uncommon because Bundler does not vendor git gems by default, it needs to be explicitly enabled with the cache_all setting.
@deivid-rodriguez did you restore the old functionality in Bundler 2.6.0? Saw a mention along those lines in:
- https://github.com/rubygems/rubygems/pull/8296
Ie, would that make this fully backwards compatible rather than a "backwards-compatible via what's effectively a one-way migration"?
Yes! I plan to release Bundler 2.6.0 next week including that change, so I guess the easiest way is to upgrade all the way to Bundler 2.6.0.