Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set BUNDLER_VERSION to the specific installed version in native helpers #5044

Merged
merged 3 commits into from
Apr 25, 2022

Conversation

brrygrdn
Copy link
Contributor

We've encountered an issue in the move forward to bundler 2.3.12 where our approach to setting the BUNDLER_VERSION in native helpers now behaves differently.

Using v0.182.0, you can observe the behaviour like so:

$ cd bundler/helpers/v1
$ bundle install
$ BUNDLER_VERSION=1.14.6 bundler -v
> Bundler version 1.17.3

On main the behaviour is like so:

$ cd bundler/helpers/v1
$ bundle install
$ BUNDLER_VERSION=1.14.6 bundler -v
> Bundler version 2.3.12

We updated this behaviour in #4132 when we noted that passing in just the major version, i.e. BUNDLER_VERSION=1 no longer worked and we started using the detected version instead, which bundler would previously 'guess' at a near match.

The change

This modifies our native_helper function to set the BUNDLER_VERSION to the actual version of v1.x or v2.x we have installed according to the detected major version.

In retrospect, this feels a little bit like it was working by accident and we were relying on bundler doing some magic for us, so I think this is a more correct approach.

@brrygrdn brrygrdn requested a review from a team as a code owner April 25, 2022 18:57
Copy link
Member

@landongrindheim landongrindheim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable to me!

bundler/lib/dependabot/bundler/native_helpers.rb Outdated Show resolved Hide resolved
@@ -47,7 +47,7 @@ def self.run_bundler_subprocess(function:, args:, bundler_version:, options: {})
args: args,
env: {
# Bundler will pick the matching installed major version
"BUNDLER_VERSION" => bundler_version,
"BUNDLER_VERSION" => installed_bundler_version(major_bundler_version),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"BUNDLER_VERSION" => installed_bundler_version(major_bundler_version),
"BUNDLER_VERSION" => installed_bundler_version(bundler_major_version)

Copy link
Member

@Nishnha Nishnha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice spot! This fix seems fine to me.

I think in a future PR we can improve on how we use use the env variable that we set here.

The "BUNDLER_VERSION" env variable is passed in when executing a run_helper_subprocess command, but it's not an officially supported/documented feature.

Maybe we should swap it for using rubygem's bundle version prefixes instead?

@brrygrdn
Copy link
Contributor Author

@Nishnha yeah, this is very much a minimal patch possible - I think #4973 represents a good candidate for a 'proper' fix.

@brrygrdn brrygrdn enabled auto-merge April 25, 2022 19:56
@brrygrdn brrygrdn merged commit 355c453 into main Apr 25, 2022
@brrygrdn brrygrdn deleted the brrygrdn/fix-bundler-version-passed-to-cli branch April 25, 2022 20:05
@brrygrdn brrygrdn mentioned this pull request Apr 25, 2022
mctofu added a commit that referenced this pull request Apr 25, 2022
…-version-passed-to-cli"

This reverts commit 355c453, reversing
changes made to c55e5f8.
@deivid-rodriguez
Copy link
Contributor

Hi folks, sorry about this issue.

I believe it must've been the rubygems upgrade that actually caused this, since it's where the code to activate the Bundler gem lives.

In particular, I reviewed the changelog and it must've been rubygems/rubygems#5181. Indeed, although the goal was to remove hard errors when activating Bundler, this "magic" was also removed from rubygems and now BUNDLER_VERSION only activates the exact version if present but applies other filtering using the major version only.

This change looks good to adapt to that, and I think #4973 should also fix this.

@brrygrdn
Copy link
Contributor Author

@deivid-rodriguez Thanks for checking in - we've been testing this fix out but it seems like while it changes behaviour it doesn't remediate the issue downstream.

Part of the issue is a lack of an integration test in core that checks the functionality thoroughly so we couldn't really detect this until it was added to an internal integration suite. We're going to rollback the rubygems upgrade as we've confirmed that does resolve the issue and then regroup on how we can roll forward.

The long tail while be figuring out how we can move some testing around this earlier in the feedback loop so we don't have to revert contributions, which feels bad.

@deivid-rodriguez
Copy link
Contributor

Don't worry about reverting, I'm glad you have further checks down to the road to detect this kind of issue on time.

@jeffwidman jeffwidman mentioned this pull request Aug 3, 2022
jeffwidman added a commit that referenced this pull request Oct 7, 2022
Bump Rubygems to `3.3.22`:
https://github.com/rubygems/rubygems/blob/master/CHANGELOG.md#3322--2022-09-07

There's some prior history here:
1. Originally bumped from `3.2.20` to `3.3.11` in #5035. That changed how bundler
   version detection worked, which caused some problems.
2. We attempted to workaround the issue in
   #5044, but that
   wasn't sufficient.
3. So in #5048 we
   rolled back to `3.2.20`
4. However, as part of the Ruby 3.1 upgrade, we _have_ to bump to
   Rubygems `>=3.3.3`... so we need to figure out a fix.
5. Now that `updater` is merged into `core`, we can have the full test
   suite checking the results, and don't have to bump in `core`, then
   pull into `updater` and see if it passes a separate CI... the
   two-step dance was the reason why this wasn't caught in the original
   core PR but instead merged and then reverted.
6. I am reasonably sure that @deivid-rodriguez figured out a way around
   the Bundler version difficulty in
   #5513, so this PR
   requires that to land first.
7. Originally I had the Rubygems upgrade bundled as part of the Ruby 3.1
   upgrade, but now that we have a better understanding of what's
   happening, we should be fine to do these changes independently...
   which lets us more easily debug if we do happen to encounter problems.
   So I am splitting this out as a separate PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants