Started receiving a warning asking to run `gem update --system`

[DannyBen]

While testing something that used to pass without a problem many times before, I just started receiving a warning in Ruby 2.7.

Your RubyGems version (3.1.6) has a bug that prevents required_ruby_version
from working for Bundler. Any scripts that use gem install bundler will break
as soon as Bundler drops support for your Ruby version. Please upgrade RubyGems
to avoid future breakage and silence this warning by running gem update --system 3.2.3

This is displayed right after one of my tests executed bundle exec <something>

Not sure if this is a bug, or not - but I hope I don't need to manually add gem update --system to all my workflows.

The run is here: https://github.com/DannyBen/bashly/actions/runs/3770607372/jobs/6410550361
The workflow is here: https://github.com/DannyBen/bashly/blob/master/.github/workflows/test.yml

[dentarg]

Your workflow run that failed is using bundler-2.4.0 (released today). The previous run that worked was using bundler-2.3.26.

I don't think your issue should be addressed in setup-ruby.

I think your options are either picking the bundler version (bundler option) or RubyGems version (rubygems option) (e.g. you can tell setup-ruby to install the latest RubyGems version with input latest).

[DannyBen]

Thanks for the details. I will replace my manual gem update --system with the rubygems: latest option.

However, doesn't this mean that all users will have to do it? Or will this fix itself in time when the latest bundler is propagated?

[dentarg]

I guess that depends, if their usage are sensitive to the warning that Bundler 2.4.0 prints (and I don't know if it is always printed or if some particular use-case triggers it). I don't think it will be common that the warning will fail builds.

[DannyBen]

Thank you. I will close the issue then, appreciate the help.
(perhaps enabling Discussions on this repo would allow issues like this to be opened without contaminating the issues section?)

[dentarg]

I don't mind issues (but it is up to @eregon for this repo). I think I like issues more, for most things, as issues can be closed. I like that signal, "we have moved on from this, it has been taken care of". Discussions on the other hand are open forever so it is hard to know if there's something in them that needs to be acted on. I guess that is a good thing for highly active projects; start with a discussion and create an issue if there's something the needs to be acted on.

[eregon]

@deivid-rodriguez What do you think about this?

as soon as Bundler drops support for your Ruby version

That doesn't sound likely to happen soon since this is Ruby 2.7, right? Like it will be years before this matters.
So it seems a warning which doesn't need to be acted on to me (well, except it can break tests like here).
Maybe we should even suppress this warning somehow in setup-ruby? (although I agree this issue is completely independent of setup-ruby)

IMHO updating RubyGems for this is overkill and introducing more instability into existing builds.

[DannyBen]

IMHO updating RubyGems for this is overkill and introducing more instability into existing builds.

Wait... so what are my other options that will not be an overkill? (assuming any output to stdout/stderr is a part of my tests, since I am testing a command line).

[eregon]

I would expect for most jobs it wouldn't fail the test suite.
For your case, maybe ignore the STDERR output, or maybe there is an ENV var or something to tell Bundler to not emit this warning.

[DannyBen]

Hmm. Well, ignoring is not an option - the purpose of these CLI tests is to ensure the output is exactly as expected, with no errors. This warning is going to be a problem for anyone with the same situation, running bundle exec <something> (regardless of my gem), which will lead them to follow the instructions and update rubygems...

I will leave it as is for now, and monitor if it causes future issues.

[deivid-rodriguez]

That doesn't sound likely to happen soon since this is Ruby 2.7, right?

We plan to do this next year, since Ruby 2.7 will reach its end of life date in March. Hence, we started warning this now.

This will be the last version where we will display this warning, because more recent Rubies all have a RubyGems version that can deal with required_ruby_version properly.

All in all, I don't think any action is needed here nor in ruby/setup-ruby nor on the RubyGems side. I think the combination of tests depending on exact CLI output, and CI not using locked versions of software gets pretty brittle and not much we should do about it.

But let's see how many people are affected by this and we can reconsider if necessary.

[deivid-rodriguez]

My recommended solution is, of course, to upgrade RubyGems by the way :)

[DannyBen]

I think the combination of tests depending on exact CLI output, and CI not using locked versions of software gets pretty brittle

When testing a gem that is a CLI, I don't see a way around it.

1. Exact CLI output is expected, because this is the product we give users.
2. Versions are not locked since Gemfile.lock is not in the repo, and gemspec is using optimistic versioning allowing users to have the latest of everything.

Am I not following best practices?

[deivid-rodriguez]

I like to have a CI that always uses the same version of dependencies, unless I explicitly change them. But that's just my personal take, I understand others having different opinions!

Sorry this broke your build, please use rubygems: latest for now and we'll see how many other people are affected.