Migrate from actions/setup-ruby to ruby/setup-ruby

[jeffwidman]

The actions/setup-ruby action was deprecated in favor of ruby/setup-ruby.

So this switches to that.

Reading the docs for ruby/setup-ruby, all the examples include the
following params:

with:
        ruby-version: '3.0' # Not needed with a .ruby-version file
        bundler-cache: true # runs 'bundle install' and caches installed gems automatically

However, the ruby-version looked like it needed to be specified for
actions/setup-ruby as well, and it wasn't, so maybe there's a default
that suffices?

And I suspect the bundler-cache arg is only relevant for repeated calls to ruby/bundler
within a single CI run... whereas we only call this action once for the following ruby call:

gem install rake && rake gems:release

So I doubt that caching adds value.
Happy to be proved wrong if someone more familiar with Ruby knows more.

[jeffwidman]

I'm not really sure how to test this... I have a funny feeling the only way is by cutting a release which should trigger this workflow to push the gem to rubygems...

[jeffwidman]

@deivid-rodriguez can you please review this? In particular, see my comments on the PR description mentioning several args which I'm unclear whether should be included or not...

[jeffwidman]

Actually, I wish there was an officially supported action for publishing to RubyGems... that would bypass a lot of what we've got here, no need to create a custom ~/.gem/credentials file etc...

I poked around, but all I could find were actions maintained by individuals, which I'm a bit leery of relying on for both security and stability concerns. Couldn't find anything maintained by Ruby / Ruby Gem organizations...

[deivid-rodriguez]

Hi @jeffwidman!

I don't think you're using Bundler at all, here. If that's the case, you definitely don't need bundler-cache: true, and you don't even need Bundler at all so you could potentially specify bundler: none although I think that has effectively become the default in absence of a Gemfile.lock file, so I'd leave that alone.

And regarding automatic gem release action. Yes, there's nothing official yet. I think it's mainly because "automatic releases" required disabling two factor authentication or at least some complicated trickery to make it work with it. I think it would be a great idea to push for something fully secure and official, I will ask around!

[jeffwidman]

Thank you for looking this over.

I think it's mainly because "automatic releases" required disabling two factor authentication or at least some complicated trickery to make it work with it.

Interesting. Looks like the current code here is already able to publish without 2FA though for some reason.

[deivid-rodriguez]

Interesting indeed. Have a look at rubygems/rubygems.org#2500. There used to be the workaround of setting "UI only" as the MFA level, but that effectively means disabling MFA, and that will be deprecated because it's misleading. At the end of the linked thread there's another approach for automatically generating MFA codes that should be secure I think. But in any cases, a proper action would be great.

[Nishnha]

Maybe we should include

with:
    ruby-version: '2.7.6'

for this deploy and remove it in a future deploy since we don't know what the default version is and we don't have a .ruby-version file in repo

[deivid-rodriguez]

I think using the same version used elsewhere is a good idea 👍.

[jeffwidman]

I'm actually hesitant to pin to a specific ruby version because it's so easy to go out of sync with our other code... for example, in #5432 I caught that we'd forgotten to bump a similar version pin.

And in order to merge #5030 we are likely going to bump to Ruby 3.1...

I'm not very knowledgable on ruby tooling, but I wonder... since this workflow is simply uploading the gem to rubygems, does it even matter what the Ruby version is? Ie, as long as it's a relatively recent version, won't the gem push succeed?
Or does the Ruby version have to match the gem version somehow?

This isn't something I feel strongly about, so if there's a reasonable case for pinning the version, I'm happy to do it, but thought I should raise these questions first...

[deivid-rodriguez]

I don't think it has to match, specially here since as you explained is just about releasing gems. But I personally like to use the same fixed version everywhere. You're right that doing that would require extra work to not fall out of sync, but even if it falls out of sync, you're at least always using a fixed version for releasing and can be sure that a Ruby being released with some bug that affects this task can't ever affect it (I know it's very unlikely, but still).

[jeffwidman]

I wonder if it might make more sense to specify a .ruby-version file to the repo? That would let us not only not pin here, but also Rubocop and other tooling would honor it: https://docs.rubocop.org/rubocop/configuration.html#setting-the-target-ruby-version

But this is a library, so we'd be tying the hands of our users, which we probably don't want to do...

Anyway, for now to get this across the line I'll pin it manually, and then have a separate conversation about pros/cons of switching to using .ruby-version...

[deivid-rodriguez]

I think a .ruby-version file is a nice idea to keep things in sync more easily. And since it's not shipped with the library, it shouldn't force end users to use an exact Ruby version, which would be a bad idea indeed. The only thing that affects end users is the required_ruby_version field in gemspec, which should only set a lower bound for the Ruby version and we should be able to keep in sync easily through RuboCop too.

[jeffwidman]

And since it's not shipped with the library, it shouldn't force end users to use an exact Ruby version

Oh interesting, didn't realize it wasn't shipped with the gem. In that case, we should probably use that. I'll opened #5483 to add that.

[jeffwidman]

I discussed with @Nishnha on slack, and he was also in favor of using .ruby-version file rather than pinning in the action, so going to merge w/o an explicit Ruby version pin in this action and rely on #5483.