integration tests

[3v0k4]

This PR takes care of the following:

• use CircleCI configuration v2.1
• (besides the gem tests) run integration tests by cloning rails-app-with-knapsack-pro
• remove the CodeClimate ENV because we are not using it
• make sure Rubocop exits with an error if there's an offense (and fix a small offense)

This setup catches:

• 231 (https://app.circleci.com/pipelines/github/KnapsackPro/knapsack_pro-ruby/1055/workflows/3dd23caf-13d7-4683-b11e-dd5aacf969cf/jobs/2421, https://app.circleci.com/pipelines/github/KnapsackPro/knapsack_pro-ruby/1055/workflows/3dd23caf-13d7-4683-b11e-dd5aacf969cf/jobs/2429)

• 233 (https://app.circleci.com/pipelines/github/KnapsackPro/knapsack_pro-ruby/1059/workflows/b46cd967-adad-4615-9837-ae932f1ff703)

See the builds for this branch on CircleCI.

I decided not to add the next version of ruby (3.3) because it would be more complex than waiting for CircleCI to add it to their cimg images.

[3v0k4]

@ArturT @shadre how many versions of Ruby and RSpec do we want to test on CI? I'd say that last 3 of both (that would include Ruby 3.3 as soon as CircleCI publishes the image is a good starting point.

[ArturT]

@ArturT @shadre how many versions of Ruby and RSpec do we want to test on CI? I'd say that last 3 of both (that would include Ruby 3.3 as soon as CircleCI publishes the image is a good starting point.

RSpec:

• We should not test RSpec 2.x because we dropped support for it.
• The last 3 versions sounds fine. But I'm wondering if we should have some versions fixed. For example 3.10 because we wanted to support some users, fix in 6.0.1.

If we would keep only last 3 versions and there is a new version of RSpec, should we drop code that supports RSpec 3.10? If so, then we risk that some old users might have again problem to onboard the knapsack_pro gem. I'd just keep 3.10 fixed. And keep adding new RSpec versions (latest minor versions).

Example:

• 3.10 (fixed version, we want to test it on CI because our code is specific to this version)
• 3.11.x (not testing anymore on CI) Last 3 minor versions that we test always:
• 3.12.x
• 3.13.x
• 3.14.x

Other than that we may consider tracking RSpec, Ruby versions in API so that we could better understand the users environment. This way we would know if it makes sense to drop RSpec 3.10 support or not.

Ruby:

We can test on CI the last 3 minor versions of Ruby: 3.0.x, 3.1.x, 3.2.x.

As an exception when there is a new Ruby preview/rc release that we want to test for example ruby 3.3.0-rc1 then we can add it to the list.

Example:

• 3.0.x
• 3.1.x
• 3.2.x
• 3.3.0-rc1

When 3.3 is official then we can get rid of 3.0.x or when it's not supported anymore.

Example:

• 3.1.x
• 3.2.x
• 3.3.x

I decided not to add the next version of ruby (3.3) because it would be more complex than waiting for CircleCI to add it to their cimg images.

Ok. We don't have to add it now.

[shadre]

@ArturT @shadre how many versions of Ruby and RSpec do we want to test on CI? I'd say that last 3 of both (that would include Ruby 3.3 as soon as CircleCI publishes the image is a good starting point.

@ArturT @3v0k4 I'm leaving the specifics for the both of you to decide on.

My 2 cents is that we don't want to drop testing older versions sooner than the customers realistically bump them. Otherwise, this feature would be providing close to zero value after some time (as we wouldn't be covering the inevitable bugs that some customers that are slower to update will experience). How that translates to exact delta in versions - I don't know. But I'd like us to keep this point in mind. Another consideration is how much slower it would be for us to test additional versions.