Add constraint to ActiveSupport gem to use version lower than 7.1

[ahasunos]

Description

The latest version of ActiveSupport i.e. 7.1.0 - released on October 05, 2023 results to an issue as:

/.rbenv/versions/3.1.4/lib/ruby/gems/3.1.0/gems/activesupport-7.1.0/lib/active_support/core_ext/array/conversions.rb:108:in `<class:Array>': undefined method `deprecator' for ActiveSupport:Module (NoMethodError)

  deprecate to_default_s: :to_s, deprecator: ActiveSupport.deprecator
                                                          ^^^^^^^^^^^
Did you mean?  deprecate_constant

More details on the issue can be found here: https://github.com/rails/rails/issues/49495

We plan to remove the version constraint post stable release of ActiveSupport 7.1

Related Issue

Fixes #750

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New content (non-breaking change)
• [ ] Breaking change (a content change which would break existing functionality or processes)

Checklist:

• [x] I have read the CONTRIBUTING document.

[ahasunos]

The omnibus build fails because Mocha ~1.1 is incompatible with minitest v5.19 and later with an error as:

.rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/mocha-1.16.1/lib/mocha/integration/mini_test/adapter.rb:26:in `included': uninitialized constant MiniTest (NameError)

          Mocha::ExpectationErrorFactory.exception_class = ::MiniTest::Assertion
                                                           ^^^^^^^^^^
Did you mean?  Minitest

Build link here: https://buildkite.com/chef-oss/inspec-train-main-verify/builds/876

This would require upgrade to mocha and rename the occurence of MiniTest::Mock.new to Minitest::Mock.new in our codebase.

[ahasunos]

Build where it failed for windows on ruby lower than 3.1 with mocha ~1.1: https://buildkite.com/chef-oss/inspec-train-main-verify/builds/880

[ahasunos]

Taking care of mocha in a separate PR: #752

[Schwad]

We plan to remove the version constraint post stable release of ActiveSupport 7.1

Just as a headsup, ActiveSupport 7.1 as released is stable. Rafael from the core team gives a bit more clarification around this here (which is why the issue was closed as not planned) :

If you are not in a Rails application (that already does that for you automatically), you should always require active_support beforing requiring anything else inside active_support. This is a requirement from the framework since the beginning. See https://guides.rubyonrails.org/active_support_core_extensions.html#stand-alone-active-support This is an issue in CocoaPods, or any gems that requires Active Support features before requiring the active_support entrypoint.

Hope this context helps! :)

[ahasunos]

We plan to remove the version constraint post stable release of ActiveSupport 7.1

Just as a headsup, ActiveSupport 7.1 as released is stable. Rafael from the core team gives a bit more clarification around this here (which is why the issue was closed as not planned) :

If you are not in a Rails application (that already does that for you automatically), you should always require active_support beforing requiring anything else inside active_support. This is a requirement from the framework since the beginning. See https://guides.rubyonrails.org/active_support_core_extensions.html#stand-alone-active-support This is an issue in CocoaPods, or any gems that requires Active Support features before requiring the active_support entrypoint.

Hope this context helps! :)

Thanks @Schwad! Requiring active_support before requiring anything else inside active_support fixes the issue.

[ahasunos]

Closing this PR. As it is getting addressed on inspec-k8s resource pack's end here: https://github.com/inspec/inspec-k8s/pull/37