Run supported ruby versions with supported Rails versions

[kbrock]

Overview

I made the test run locally on my machine.

Dependencies

• [x] #250

Versions in matrix

I chose the max ruby version that runs with the corresponding rails version. This seemed to cover most of the ruby and rails versions.

• If the rails version was EOL, I saw no reason to add to a matrix and test with more than one ruby version.
• If the ruby version was EOL, I saw no reason to add to a matrix and test with more than one rails version.

Since all ruby versions under 3.0 were tested in at least one configuration, it seemed logical to only add ruby 3.0 to the matrix.

All supported versions of rails were added to the matrix. I did hold off on 7.0 since that build does not run and that is best for another

I'm hoping this is a nice mix between testing every version of rails, every version of ruby, and not taking too long / using up too many resources for testing redundant configurations.

What was out of scope

While I did add a rails 7.0 gemspec, fixing the suite was out of scope. Once that runs, we can uncomment the line in the travis.yml

Sources

• https://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html
• https://www.fastruby.io/blog/ruby/rails/versions/compatibility-table.html
• https://www.ruby-lang.org/en/downloads/branches/ (support dates for ruby versions)
• https://www.ruby-lang.org/en/downloads/releases/ (latest ruby version in each branch)
• https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#expanding-or-adding-matrix-configurations

[kbrock]

@syguer I had merged a few PRs and wanted to make sure that the suite was still green. When I downloaded to run it, things were in a little off. Hope you like these changes.

I can merge if you are too busy, but would prefer to get your ok.

[kbrock]

update:

• still support deprecated versions of rails and ruby. But don't run so many combinations on EOL versions

[kbrock]

update:

• changed version checking to be Psych based (and not ruby based)

[kbrock]

@yujideveloper do you want me to pull out the rspec changes (autorun and expect) for an easy merge?

Do you also consider the YAML change an easy merge?

[yujideveloper]

@kbrock

do you want me to pull out the rspec changes (autorun and expect) for an easy merge?

I think it's better to pull out, but I think it's okay as it is.

Do you also consider the YAML change an easy merge?

I think it is easy merge, but I have one concern in https://github.com/active-hash/active_hash/pull/246#discussion_r853352555.

[kbrock]

update:

• extracted code changes to another PR
• changed YAML.load to YAML.unsafe_load
• removed those commits from here

[adampal]

@kbrock now that we've cut over to GitHub Actions, is this PR still required?