-
-
Notifications
You must be signed in to change notification settings - Fork 263
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
Should we use the latest Bundler release or the Bundler shipped with that Ruby by default? #358
Comments
I of course prefer the latest version than the default version. And I disagree the default version is more tested, sometimes the default version is only cherry-picked by ruby-core a few days days before releases. Yes, we sometimes introduce regressions, but those regressions could also happen in the default version (and it wouldn't be the first time). If you change this, you'll get the opposite problem, people might run into issues already fixed in the latest version. |
Right, this is different for CRuby. For TruffleRuby I can definitely say the default version is more tested (e.g. I use/"test" it a lot more than "all newer Bundler versions"). And since it is a version used in a CRuby release, potential issues are typically well known or also seen in local development.
True. At least they can easily use I think FWIW setup-ruby used to only install bundler for Rubies without Bundler. |
Well, although I disagree with the argument that "default is more stable than latest", I'm always in for CI stability, so I agree with your point about variability, and I agree using the default version is probably a better default, indeed. |
I can see it being 50/50 between the two options. Either you run into problems fixed in the latest version of Bundler or you run into some incompatibility with latest Bundler. 😅
I agree with this. Not doing that (The sped up may be defeated by the fact that a recent enough Bundler will switch (install the later version) to the version you specified in your lockfile? If you are keeping up with Bundler releases in your lockfile, that is.) |
Great, it seems we all 3 agree the Bundler shipped with that Ruby should be used by default, for CI stability.
Yes, on CRuby it's just a couple seconds or so, but on other Rubies it's longer.
If there is a Gemfile.lock with a |
No longer needed since ruby/setup-ruby#358
No longer needed since ruby/setup-ruby#358
Mmh, this seems problematic in practice unfortunately :/ with lines like this in the Gemfile: gem 'rack-test', github: 'rack/rack-test' I tried it on Sinatra's CI (sinatra/sinatra#1803):
Also it warns about insecure, but recent versions don't warn, since they actually use https for
On 2.6 I think we should probably keep installing Bundler 2 (latest Bundler 2 or maybe some known version of Bundler 2 but then which one?): #362 (comment) On 2.7, maybe we consider the Bundler 2.1.4 it has "too old" and so install latest/more recent Bundler when Bundler < 2.2? |
#363 to use latest Bundler on CRuby 2.6 & 2.7, that passes the sinatra CI: https://github.com/eregon/sinatra/runs/7527978961?check_suite_focus=true Not ideal, but I think we need something like this to not break a ton of CIs. |
No longer needed since ruby/setup-ruby#358
Actual changes with #363 merged:
So Bundler 2.2.22 is the minimum Bundler 2 version, older than that we install latest Bundler. |
I'm adding a test for this, simply That fails on Ruby 1.9 - Ruby 2.2, which all use the latest Bundler 1 (Bundler 2 requires Ruby 2.3+), specifically 1.17.3:
So Bundler 1 simply doesn't support In other words, we cannot do anything about it in setup-ruby, and I'll just exclude the test for these old Rubies. Ruby 2.6 and Ruby 2.7 fail as mentioned above with their default Bundler, we'll just use latest Bundler 2 for them. |
To have a simple consistent rule, I changed it to:
|
because ruby/setup-ruby#358 broke a lot of our CI jobs
Currently it's the former but I'm thinking to change to the latter.
But it led to several issues already, including rubygems/rubygems#5691 and previous issues where a Bundler release was broken for some aspect (I'm too lazy to search but I'd think at least 2 other issues).
To be clear, every software has bugs, I think the Bundler is doing a good job, no problem there.
But I think this is no coincidence, the Bundler shipped with a Ruby is more tested (because it's tested in that Ruby's CI rather extensively and manually during that Ruby's development) and more stable (since it doesn't change that often).
Of course, such issues in Bundler still need to be fixed and some users might need a newer Bundler than what is shipped with the Ruby.
But exposing CI users more than in local development to this kind of issues does not seem ideal.
Because in local development, one doesn't
gem install bundler
before everybundle install
.In fact I rarely do
gem install bundler
but tend to use the bundler shipped with that Ruby (mostly to not add another variable part in my environment/repro).Note we already use the "shipped" Bundler for
-head
versions, but for Ruby releases we currentlygem install bundler
.So the change would be for Ruby releases which do ship with Bundler to just use that Bundler and no longer
gem install bundler
by default. Of course one could still configure they want latest Bundler with:bundler: latest
.@MSP-Greg @dentarg @deivid-rodriguez Any opinion on this?
The text was updated successfully, but these errors were encountered: