search

travis-ci / travis-rubies

my rubies, let me show you them
http://rubies.travis-ci.org/
MIT License
42 stars 31 forks source link

Bundler is missing from non-preinstalled rubies #57

Open joshcooper opened 5 years ago

joshcooper commented 5 years ago

When running travis CI against a ruby version that isn't preinstalled, the bundler gem fails to install. For example when using ruby-2.3.7: https://travis-ci.org/puppetlabs/puppet/jobs/474973328#L466

We've worked around the issue in puppet itself, but it also affects all puppet module CI pipelines, such as https://travis-ci.com/puppetlabs/puppetlabs-cron_core/jobs/168691623#L464. It also affects customers that have written modules.

The issue is caused by the new bundler 2 release combined with travis not constraining the bundler version in gem install bundler. If you change that to gem install bundler -v '< 2' for pre-2.5 rubies, then it should work.

Note bundler 2.0.0 originally required rubygems 3, but that was relaxed to rubygems 2.5.0 in bundler 2.0.1. See https://bundler.io/blog/2019/01/04/an-update-on-the-bundler-2-release.html for more info.

Can you update the travis rubies to install a bundler version that is compatible with the ruby it's being installed into?

joshcooper commented 5 years ago

Hi @BanzaiMan @MSP-Greg, do you have thoughts about this?

BanzaiMan commented 5 years ago

I understand the concerns, but I am not exactly sure how we would best approach the problem here. If we bundle Bundler in the archive, users will have problems with an outdated version. If we do not bundle Bundler in the archive, the requirements can change at the install time and the installation fails at run time.

BanzaiMan commented 5 years ago

If you change that to gem install bundler -v '< 2' for pre-2.5 rubies, then it should work.

I don't think this would work. For Rubies 2.2.x and 2.3.x, there are perfectly legitimate RubyGems versions that satisfy the requirement (>= 2.5.0), and therefore they can use Bundler 2.0.1. Installing Bundler 1.x (instead of 2.0.1) will appear arbitrary and confusing, when a few months pass and we all forget about why such a compromise was introduced.

MSP-Greg commented 5 years ago

@BanzaiMan

but I am not exactly sure

I think a lot of people feel that way, as this is a mess. I suspect you've seen some of the discussions elsewhere.

I haven't had time to check, but a possible interim solution may be to install both Bundler 1.17.3 and 2.0.1. Then install RubyGems 2.7.8 for Ruby < 2.3, and RubyGems 3.0.2 otherwise. Whatever a solution is, it's a PITA.

Last night I was working with some testing, starting with ruby-head/trunk, then I moved to older Ruby versions. It was not pretty, and I'm used to wrestling with 'Bundler related' issues...

joshcooper commented 5 years ago

Agree this is a mess, and I don't envy your situation.

Can we install a version of bundler that is compatible with the ruby and rubygems versions present in the archive based on the output of ruby --version and gem --version? For example, ruby 2.2.9 is EOL, and it by default comes with rubygems 2.4.5.4. So it seems sane to install a compatible version of bundler (1.7.8).

Since bundler 2.0.1 and up require ruby 2.3 and rubygems 2.5, I think the support matrix is something like:

ruby rubygems bundler
< 2.3 < 2.5 < 2
< 2.3 >= 2.5 < 2
>= 2.3 < 2.5 < 2
>= 2.3 >= 2.5 any

If someone is running with ruby >= 2.3, but < 2.5 rubygems, and they require bundler >=2, then it's on them to do gem update --system && gem install bundler.

aried3r commented 5 years ago

I'm not sure if this is the same issue I'm facing, but currently it seems that Ruby 2.5 is the only one shipping with bundler 2.x while Ruby 2.6 ships with bundler 1.17.x, probably because of rubygems 3.0.2.

As you can see I tried adding some workarounds, but none of them work, making just the combination of Rails 4.2 and Ruby 2.5 fail. See all the other runs here.

BanzaiMan commented 5 years ago

@aried3r The 2.6.0 archive was created before the Bundler 2.0(.1) release, so https://travis-ci.org/rpush/rpush/jobs/486420552#L230 is correct.

Your 2.5.3 build is using Bundler from the cache. If you remove the cache from the equation, it should start out with 1.16.2.

aried3r commented 5 years ago

@BanzaiMan, thanks for the quick reply. So I guess I might start facing problems once there's a newer 2.6.x archive which ships with bundler 2.x?

I cleared all caches using the website and restarted the job, but it seems that this job still fails https://travis-ci.org/rpush/rpush/jobs/486443184

Maybe I didn't completely understand which caches you mean.

MSP-Greg commented 5 years ago

@aried3r

So I guess I might start facing problems once there's a newer 2.6.x archive which ships with bundler 2.x?

I've never seen, nor looked for a written policy, but generally, once a new Ruby version x.y.0 is released, future updates (x.y.z) seem to stay with the same std-lib/gem versions. Hence, Bundler 2.0+ will probably not be included in ruby until 2.7 release...

BanzaiMan commented 5 years ago

@aried3r I must have misspoken about the 2.5.3 archive. It's pre-installed on Xenial (my test was on Trusty), and it comes with Bundler 2.0.1. It seems to me that your attempts to uninstall Bundler 2.x are unsuccessful, and 2.0.1 is still used as a result. The commands you are running are the ones I believe to work, so I am not really sure what else to try.

We can enable the debug feature for this repository if you would like to troubleshoot this further.

aried3r commented 5 years ago

We can enable the debug feature for this repository if you would like to troubleshoot this further.

Thank you for the offer, I think I will leave things as they are now because of limited time. Should it become a bigger problem I'll certainly report back. Thanks for your help!

Hence, Bundler 2.0+ will probably not be included in ruby until 2.7 release...

Good to know, thanks!