Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub Actions updates #96

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

jgarber623
Copy link
Contributor

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 event

Allows 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!

The ruby/setup-ruby GitHub Action [1] 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.

[1] https://github.com/ruby/setup-ruby
This commit breaks out linting and testing 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.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant