This PR refactors the ruby.yml GitHub Actions workflow with a handful of changes:
1. Configure bundler cache in setup-ruby action
The ruby/setup-ruby GitHub Action supports a bundler-cache config that, "runs 'bundle install' and caches installed gems automatically." Using this configuration simplifies later job steps and speeds up subsequent workflow runs.
3. Split lint and test jobs into two separate, parallel jobs.
Since the RuboCop config specifies the target Ruby version (3.1), there shouldn't be a need to run the tool in each tested Ruby.
In this configuration, the linting job will run and report any errors in parallel with the test job(s) defined in the matrix. The previous addition that caches dependencies in the Ruby setup step should make all of this run pretty quick.
4. Don't fail fast
This setting allows all jobs in the matrix to continue to completion whether or not any of them fail along the way. This is most useful in cases where, say, Ruby 3.3 fails on an actual error but we'd want to know whether or not the same error appears in Ruby 3.2 and 3.1. Absent this configuration, if the Ruby 3.3 error was encountered first, all jobs would be cancelled without reporting success or failure of the test suite.
This PR refactors the
ruby.ymlGitHub Actions workflow with a handful of changes:1. Configure bundler cache in setup-ruby action
The ruby/setup-ruby GitHub Action supports a
bundler-cacheconfig that, "runs 'bundle install' and caches installed gems automatically." Using this configuration simplifies later job steps and speeds up subsequent workflow runs.2. Configure
workflow_dispatcheventAllows for manual running of a workflow. Occasionally handy.
3. Split lint and test jobs into two separate, parallel jobs.
Since the RuboCop config specifies the target Ruby version (3.1), there shouldn't be a need to run the tool in each tested Ruby.
In this configuration, the linting job will run and report any errors in parallel with the test job(s) defined in the matrix. The previous addition that caches dependencies in the Ruby setup step should make all of this run pretty quick.
4. Don't fail fast
This setting allows all jobs in the matrix to continue to completion whether or not any of them fail along the way. This is most useful in cases where, say, Ruby 3.3 fails on an actual error but we'd want to know whether or not the same error appears in Ruby 3.2 and 3.1. Absent this configuration, if the Ruby 3.3 error was encountered first, all jobs would be cancelled without reporting success or failure of the test suite.
Thanks for considering this change!