Use ruby/setup-ruby Github action

[ekohl]

The ruby/setup-ruby action is actually maintained by the Ruby people themselves. It has built in caching with the proper behavior. Not only is it easier to read (less syncing going on), it's also likely to be maintained properly. For example, to get proper caching of gems, bundle lock should run to get a Gemfile.lock which gives you a correct cache. This action does it for you.

Note I didn't test it myself since I don't use PDK, but we've been using this in Voxpupuli (https://github.com/voxpupuli/modulesync_config/blob/master/moduleroot/.github/workflows/ci.yml.erb) and it works well in my experience. The only thing we don't currently do is to run on push as well. That means we don't have a shared cache ready and caches are now scoped to a user. It looks like pdk-templates is in the same setup, but due to the nightly tests it probably gets away with this.

[DavidS]

Nice find!

This would also need to be added to the second time this sets up ruby at

pdk-templates/moduleroot/.github/workflows/nightly.yml.erb

Line 119 in 4543421

- name: Cache gems

(and the same for pr_test.yml.erb).

Given this section from ruby/setup-ruby:

When there is no lockfile, one is generated with bundle lock, which is the same as bundle install would do first before actually fetching any gem. In other words, it works exactly like bundle install. The hash of the generated lockfile is then used for caching, which is the only correct approach.

it does likely lead to more accurate caching, too.

[ekohl]

Something like this? I'm not sure what steps you want to log so do review that part.

[DavidS]

I've updated the PR with my thoughts:

• use ruby/setup-ruby consistently everywhere
• record bundler env on the setup matrix job too
• deploy changes to both PR and nightly job
• rejig some of the labels around the change to make more sense

While you're at it, would you mind reading through the changes in #377 ? I'd love to hear you opinion on that one, too.

[ekohl]

Good catch :)

[DavidS]

Since the meat of the two files is the same, I took on the habit of fixing one, and then copying over everything to the other (except the preamble and the slack notification) 🤷

can't wait for the day when actions support higher-level re-use - I don't want to re-compose all of this into a singular action just for this...

[ekohl]

can't wait for the day when actions support higher-level re-use - I don't want to re-compose all of this into a singular action just for this...

Oh yes, absolutely. Templating and copying over to many repos is painful.