Setup build matrix in CI #116
Conversation
|
Hey @dmathieu thanks for contributing. Any particular reason for removing the Gemfile.lock in this PR? |
|
Yes. Having it also makes it harder to have the build matrix, as the bundler version will change, and the bundler packaged with 3.0 doesn't want the old bundler version specified in this Gemfile.lock. |
|
As an example: In So if I start using this gem today, I will end up on the latest version, which is 1.7.1. While this gem keeps being tester with an earlier version. Without the Hoping that makes sense. |
|
Hi @dmathieu thanks, yes I understand the difference of the |
This is not something anyone should do in production. But in tests, this allows us to bypass CSRF.
So we're not constrained on a specific bundler version. Also, Gemfile.lock won't be used when this gem is added as a dependency anyway. If we require a specific version, it should be set in the gemspec file.
1.9 is already pretty old. There's no reason not to be able to run a newer version
So it runs a version supported by ruby 3.0
|
Hey @dmathieu after testing this PR, I agree with removing the Gemfile.lock. When testing across the multiple ruby versions, the lock file is getting in the way and causing complications. Since the Gemfile.lock only impacts development on this library, and has no impact on the consumers of this library, I think it is beneficial at this time to remove it. I'll close #117 and we will just move forward on this PR. Thanks for your contributions |
Changes
This configures CircleCI to use the build matrix, in order to run the tests on multiple ruby versions.
The version used previously was
2.5. So I've added runs for2.6,2.7and3.0as well.References
There are no references for this, outside of me wanting to check that I can safely use this gem on ruby 3.0.
Testing
This isn't changing anything for users of the gem, on the contrary. It adds more tests, as we now check every supported ruby version.
Checklist