Add earliest supported RuboCop CI check

[pirj]

Add a job to be making sure the changes in pull requests are still compatible with the earliest supported RuboCop version.

For earliest-supported-rubocop job bundle install step reports:

Fetching rubocop 0.68.1
Installing rubocop 0.68.1

Fixes #283

• make the check mandatory on GitHub

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• [-] Added tests.
• [-] Added an entry to the changelog if the new code introduces user-observable changes.
• [-] The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

[pirj]

No surprise, but it seems at least our specs do not work with 0.60.0 specified in the Gemfile:

       NoMethodError:
         undefined method `expect_correction' for #<RSpec::ExampleGroups::RuboCopCopRSpecInstanceSpy::WhenUsedWithHaveReceived:0x00007fb5b0eaa660>
         Did you mean?  expect_offense

...
1254 examples, 119 failures

expect_correction first appeared in 0.63.0.

I suggest merging #804 first.

[bquorning]

No surprise, but it seems at least our specs do not work with 0.60.0 specified in the Gemfile:

I think this is actually a good case for not including the “earliest supported RuboCop“ in the test suite: The lib code may well be compatible with the old rubocop version, but the spec code may not – and won’t need to be.

I have been playing with the idea of extracting different parts of rubocop, rubocop-performance, rubocop-rails and this project into a rubocop-dev gem. If that were realised, we might be able to reliably test against the earliest supported version of RuboCop.

[pirj]

That makes total sense to me, even though it's a bit strange to use different supported versions of RuboCop as development and runtime dependencies.

[bquorning]

Could we split this PR in two? I’d like to think some more on the “earliest” part, but “edge” is ready to merge.

[pirj]

@bquorning Fair enough.
Please check this out #821.

[pirj]

So, to summarize the problem at hand.
Cops should be compatible with the earliest version of RuboCop we claim to support.
At the same time, we want to use the latest spec helpers in the spec helper code that newer versions provide (e.g. expect_offense).
The two should not necessarily depend on each other, at least I'm not aware of the implications.

The idea was to extract spec helpers/shared examples/etc to rubocop-dev and be less conservative regarding its version, since it's only for CI/development, while continue to be as conservative as possible with supported rubocop version, and only update the dependency when necessary (like #804). Is that correct, @bquorning ?

You also mentioned there are parts in rubocop-performance, rubocop-rails, and rubocop-rspec that might find its shelter in rubocop-dev. What parts would that be?
Off the top of my head: documentation/CHANGELOG checks, generators, and common .rubocop.yml (in the form of default/config.yml?).

With the introduction of edge/earliest checks and upcoming semantic versioning in RuboCop, the idea of a centralized repository (like rspec-dev) seems to be losing points.

WDYT if we start small and extract spec helpers and shared examples to rubocop-dev, use the latest features from it without looking back? I can tackle this.

[bquorning]

WDYT if we start small and extract spec helpers and shared examples to rubocop-dev, use the latest features from it without looking back? I can tackle this.

Sounds good. We should perhaps involve the rubocop core team too.

[pirj]

Since there's no definitive conclusion on this topic, and RuboCop 1.0 is on the horizon with its more conservative cop introduction policy, I believe that following minor rubocop versions won't be a problem.
With this in mind, I'd rather close this.