Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add Ruby 3.1 to CI#558

Merged
dblock merged 5 commits intohashie:masterfrom
petergoldstein:feature/add_ruby_3_1_and_update_rubocop
Jan 28, 2022
Merged

Add Ruby 3.1 to CI#558
dblock merged 5 commits intohashie:masterfrom
petergoldstein:feature/add_ruby_3_1_and_update_rubocop

Conversation

@petergoldstein
Copy link
Contributor

In addition to adding Ruby 3.1 to the CI configuration a number of other changes were required to get everything to pass. This included:

  • Updating Rubocop to ~> 1.0 for Rubies 2.4 and greater
  • Disabling the Rubocop run in rake for Rubies before Ruby 2.4
  • Quoting '3.0' in the CI configuration to ensure it loads a 3.0.x Ruby
  • Set RUBYOPT="--disable_error_highlight" so Ruby 3.1 error matchers pass (both in CI configuration and in integration spec command)
  • Fixing a few trivial lints

Update Rubocop for recent Rubies
Disable Rubocop run for Rubies before Ruby 2.4
Quote '3.0' in the CI configuration to ensure it loads a 3.0.x Ruby
Set RUBYOPT="--disable_error_highlight" so Ruby 3.1 error matchers pass
Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I vote for upgrading rubocop and dropping some 2.x rubies.

ruby:
- 3.0
- 3.1
- '3.0'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a problem for all entries, no? Let's make them all strings.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. It's only a problem for ones that end in zeroes.

3.0 -> 3
'3.0' -> 3.0

That said, I'm happy to make them all strings if you'd like.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks nicer, but I don't care enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rolled it in to the 2.4 change.

Gemfile Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we just drop unsupported rubies and move up?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to do that too. I don't think there's much benefit to such a wide range of Ruby support. If you specify a minimum you'd like to use, I can update the PR to reflect that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dblock 2.4 is the floor for this, but if you want to pick 2.5 (which is EOLed for almost a year) or 2.6 (which is EOLing in about 2 months).

Generally I'm a big fan of keeping Ruby version range relatively narrow, and using gem versions to distinguish.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am OK with whatever gives us one single version of Rubocop without the if's.

We tend not to remove rubies in Hashie because it has such incredibly wide use unless there's a good reason, and this is a good reason.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I've put up a commit that sets the minimum version at 2.4 and updates existing code to reflect that.

Remove a number of code bits designed to support Rubies below version 2.4
Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we require Ruby 2.4 in gemspec and bump version to 5.1?

@michaelherold anything else?

Gemfile Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think we still need this.

@petergoldstein
Copy link
Contributor Author

@dblock Those updates are in with the latest commit.

@petergoldstein petergoldstein requested a review from dblock January 15, 2022 01:02
Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this! Will wait a bit for @michaelherold and will merge this week otherwise. Not sure what Danger problem is, probably something about the token and permissions changes on GH.

@petergoldstein
Copy link
Contributor Author

@dblock I'm assuming you don't need anything else from me at this point, and will just merge this when you have a chance. Please let me know if there's anything else that I can do to help this get merged. Thanks! And thanks for your work on Hashie!

@dblock dblock merged commit 3e57eb5 into hashie:master Jan 28, 2022
@dblock
Copy link
Member

dblock commented Jan 28, 2022

I merged this, thank you.

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.

2 participants

Comments