Closed teoljungberg closed 1 year ago
I could add a version lock to the gemfile to denote that we have an expected version of minitest. But since there are no other version constraints I wanted to ask first.
We are also not running bundler on CI, should that be done first as a separate PR?
What is supposed to be the benefit?
@casperisfine
What is supposed to be the benefit?
Minitest's test task has an easier time passing in options to minitest itself, compared to rake's task.
It also generates more tasks to get the slowests tests etc, if that is of interest in a future refactoring.
That being said - they have the same output which is running tests. I don't mind if we decide to ditch this in favor of rake's test task.
As for the "we are not running bundler on CI" - that means we won't get access to tools such as #253 on CI.
But that's a separate issue that I can push a PR for.
It looks like bundler is run on CI, as per:
https://github.com/fxn/zeitwerk/pull/258
But then the cache on CI needs to be bumped due to this upgrade change and we do not have that new version of minitest on the CI runs.
It's not, minitest 5.16 (where the new test task is introduced) does not support ruby 2.5 as per the CI configuration.
conflicting requirements for the Ruby version:
In Gemfile:
minitest (~> 5.16) was resolved to 5.17.0, which depends on
Ruby (< 4.0, >= 2.6)
zeitwerk was resolved to 2.6.6, which depends on
Ruby (>= 2.5)
Current Ruby version:
Ruby (= 2.5.9)
Therefore with the current Ruby 2.5 and above CI policy - this is not a doable addition.
Thanks anyway for looking into this!
This is available since Minitest v5.16.0 and the following commit:
https://github.com/minitest/minitest/commit/73692f9202fbe8dcfe3069708beff155cdffa9bc