Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.2. Configure
workflow_dispatch
eventAllows 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!