Fix failing build and upgrade dev dependencies

[pkuczynski]

@rubyconfig/maintainers do anybody might have an idea why the test started to fail suddenly from #277? I tried to fix it, but failed :(

[pkuczynski]

@eregon do you think your ruby 2.7 build might be a failure? Older ruby works no problem...

[eregon]

@eregon do you think your ruby 2.7 build might be a failure?

That doesn't put me in the right mood :wink: AFAIK it works fine for many other projects, I'd assume trying to uninstall bundler is causing this,

[amatsuda]

I do something like this for gems that I maintain. https://github.com/kaminari/kaminari/blob/cd8601c/.travis.yml#L33-L35 https://github.com/haml/haml/blob/598f2b3/.travis.yml#L103-L106 It looks super ugly but works for me...

[amatsuda]

I mean, these aren't using GH Actions but you might get the basic idea.

[pkuczynski]

@amatsuda I was doing something similar and it always worked, but now fails for strange reason for ruby 2.7. @eregon even when I remove the manual bundler install in https://github.com/rubyconfig/config/pull/278/commits/91f79387dde2824dac0bb1b44e6d49d4606094b7, it still fails:

https://github.com/rubyconfig/config/pull/278/checks?check_run_id=745093503

That's really strange!

[pkuczynski]

Seems that forcing bundler: 1 as @eregon suggested solved the problem. However, I need to figure out how to force it only for old rubies.

[eregon]

However, I need to figure out how to force it only for old rubies.

Why not just using Bundler 1 for all?

[eregon]

I would be OK to add a new value for the bundler input in setup-ruby to do something like "Bundler 1 when no stdlib Bundler, otherwise use the stdlib Bundler." (which is what old versions of setup-ruby used to do, but I thought in general it's better to have the same Bundler major version for all in a given project). Would need to find a name for it though.

[pkuczynski]

However, I need to figure out how to force it only for old rubies.

Why not just using Bundler 1 for all?

I am not sure if forcing bundler 1 for newer rubies, while by default they come with bundler 2, is a good idea?

[eregon]

That's only for Ruby 2.7 (and head), but yeah.

So, bundler: 1 will install Bundler 1, but it will not remove the stdlib Bundler 2 on 2.7. So if you bundle install after it should use Bundler 2, and using bundler: 1 should be harmless.

[eregon]

Setting BUNDLER_VERSION will probably force a given version of Bundler though when running bundle ....

[pkuczynski]

Seems that the only combination which was successful was indeed when I put bundler: 1, so I will go with it...

[pkuczynski]

I am only wondering why despite restoring the cache, still some gems are being installed instead of simply used:

https://github.com/rubyconfig/config/pull/278/checks?check_run_id=745205428

Cache restored from
Run actions/cache@v1
Cache Size: ~3 MB (3013507 B)
/bin/tar -xz -f /home/runner/work/_temp/ada22154-b74b-4458-98b1-44479ed85ef8/cache.tgz -C /home/runner/work/config/config/vendor/bundle
Cache restored from key: ruby-2.7-gems-7684999e235dd298919f150070c51454b6cc335d8d6f7072cbae7b97ed8a81a2-ac399a4123b6b2035ed76ffba43ee34c8ecc81d1b548466bde0b60e35fa9d691

and then:

Resolving dependencies....
Using rake 12.3.3
Using concurrent-ruby 1.1.6
Fetching i18n 1.8.3
Installing i18n 1.8.3
Fetching minitest 5.14.1
Installing minitest 5.14.1
Fetching thread_safe 0.3.6
Installing thread_safe 0.3.6
Fetching tzinfo 1.2.7
Installing tzinfo 1.2.7
Fetching activesupport 5.0.7.2
Installing activesupport 5.0.7.2
Fetching builder 3.2.4
Installing builder 3.2.4

That happens only for bundle exec appraisal install step... Any idea?

[eregon]

I'm not sure, maybe it's installing to a different vendor directory and not capturing that one in the cache?

[pkuczynski]

I'm not sure, maybe it's installing to a different vendor directory and not capturing that one in the cache?

Any idea how to debug it?

[eregon]

I would try to reproduce it locally and see what works/doesn't.