* Add Ruby 3.1 to CI
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
* Add CHANGELOG.md entry
* Re-add deleted line from CHANGELOG.md
* Set minimum supported Ruby version to 2.4.
Remove a number of code bits designed to support Rubies below version 2.4
* Bump version. Remove unneeded require from Gemfile. Add require to spec/support file
* Update github urls to hashie/hashie
* Point omniauth in integration tests at master.
Until omniauth releases the changes merged from
https://github.com/omniauth/omniauth/pull/977 , we must point at
master branch.
* revert incorrect change of gem email
Co-Authored-By: Michael Herold <github@michaeljherold.com>
* Reference open issue for release
This is a big step forward in our Rubocop setup. I addressed all of the todos
from the current version of Rubocop that made sense to. The only things that
remain are metrics and one cop that relies on the line length metric to work.
I made some judgment calls on disabling a few cops:
1. The `Layout/IndentHeredoc` cop wants you to either use the squiggly heredoc
from Ruby 2.3 or introduce a library. Since we are a low-level library that
is used as a transitive dependency, we cannot introduce another library as a
dependence, so that option is out. Also, we support Rubies back to 2.0
currently, so using the squiggly heredoc isn't an option. Once we remove
support for Rubies older than 2.3, we can switch to the squiggly heredoc cop.
2. The `Naming/FileName` cop was reporting false positives for a few files in
the repository, so I disabled it on those files.
3. The `Style/DoubleNegation` cop reports lints on a few cases where we use
double negation. Given the very generic nature of Hashie, the double-negation
is the easiest, clearest way to express that we want an item to be a Boolean.
I disabled the cop because we exist in the gray area where this makes sense.
The Elasticsearch gems heavily integrate with Hashie. This leads people to want
to use a Mash as the backer for an Elasticsearch model, but the behavior is
different than they expect. By having this integration spec, we're covering two
things:
1. It might help ensure that we don't break the Elasticsearch ecosystem with
changes in Hashie as has happened in the past.
2. It communicates some gotchas that happen with using a Mash as the backer for
an Elasticsearch model.
In some circumstances when a project has the Rails constant defined we
may still not be able to require the rails/railtie dependency. Before this
change this would raise an exception. This change seeks to add better
detection of the railtie dependency and add logging that this dependency
is missing but still allow execution to continue.
This standardizes the way we're loading the example applications for the
integration tests so we're actually testing the behavior of the
application in each case. They're also structured in such a way to test
that the Hashie logger doesn't accidentally write to the STDOUT during
the initialization process of the applications.
We have a nice integration spec harness, so let's make sure we use it
when we're working on the gem. I'm making the following changes:
* Make `bundle exec rake` run integration specs, except on Travis.
* Silence a warning in the OmniAuth integration spec that has nothing to
do with Hashie.
* Make Guard run integration specs when appropriate. Now, when you run
all tasks you will run integration specs. Also, if you modify an
integration spec, it will run. Lastly, if you modify anything in `lib`
the integration specs will run.
* Keeps the extra Travis build that only runs integration specs. Travis
didn't like the Rake task that included it and there's extra signal by
doing it this way anyway.
Peter Goldstein