The bin shim provides by `chromedriver-helper` gem has renamed to
`chromedriver-helper` since 2.0.
https://github.com/flavorjones/chromedriver-helper/pull/58
Since bin of new name is set to driver path in
`lib/chromedriver-helper.rb`, need to load it.
## Summary
RuboCop 0.58.2 was released.
https://github.com/rubocop-hq/rubocop/releases/tag/v0.58.2
And rubocop-0-58 channel is available in Code Climate.
https://github.com/codeclimate/codeclimate/releases/tag/v0.76.0https://github.com/codeclimate/codeclimate/commit/38f21f0
In addition, the following changes are made in this PR.
- Replace Custom cops with Rails cops
- Add jaro_winkler gem to Gemfile.lock
### Replace Custom cops with Rails cops
These are compatible replacements.
- Replace `CustomCops/AssertNot` cop with `Rails/AssertNot` cop.
- Replace `CustomCops/RefuteNot` cop with `Rails/RefuteMethods` cop.
With this replacement, it was decided to use cop of RuboCop itself.
It removes the code related to CustomCops accordingly.
### Add jaro_winkler gem to Gemfile.lock
Since RuboCop 0.57.0 depends on jaro_winkler gem,
it has been added to Gemfile.lock.
We added `assert_not` in f75addd "to replace warty 'assert !foo'".
fa8d35b agrees that it is warty, and so do I. This custom Rubocop rule
turns the wart into a violation.
As with my last custom cop, https://github.com/rails/rails/pull/32441,
I want to make sure this looks right on code climate before pushing
another commit to autocorrect everything.
@toshimaru I just noticed
https://github.com/toshimaru/rubocop-rails/pull/26
Is there a better way to add these custom cops, or were you saying we
shouldn't have custom cops at all?
Since at least cf4afc4 we have preferred `assert_not` methods over
`refute` methods. I have seen plenty of comments in PRs about this,
and we have tried to fix it a few times (5294ad8, e45f176, 8910f12,
41f50be, d4cfd54, 48a183e, and 211adb4), but the `refute` methods
keep sneaking back in.
This custom RuboCop will take care of enforcing this preference, so we
don't have to think about it again. I suspect there are other similar
stylistic preferences that could be solved with some custom RuboCops, so
I will definitely keep my eyes open. `assert_not` over `assert !` might
be a good candidate, for example.
I wasn't totally sure if `ci/custom_cops` was the best place to put
this, but nothing else seemed quite right. At one point I had it set up
as a gem, but I think custom cops like this would have limited value
in another context.
I want to see how code climate handles the new cops before
autocorrecting the existing violations. If things go as expected, I will
push another commit with those corrections.
* Move system tests back into Action Pack
* Rename `ActionSystemTest` to `ActionDispatch::SystemTestCase`
* Remove private base module and only make file for public
`SystemTestCase` class, name private module `SystemTesting`
* Rename `ActionSystemTestCase` to `ApplicationSystemTestCase`
* Update corresponding documentation and guides
* Delete old `ActionSystemTest` files
Renames `Rails::SystemTestCase` to `ActionSystemTest` and moves it to a
gem under the Rails name.
We need to name the class `ActionSystemTestCase` because the gem expects
a module but tests themselves expect a class.
Adds MIT-LICENSE, CHANGELOG, and README for the future.
In listen 3.0.4 and below, the `#stop` method on the notification
backends are a no-op, meaning that we are leaking them per test. This
ended up triggering another bug in Ruby that causes our builds to fail
randomly on CI.
listen bug: https://github.com/guard/listen/issues/353
ruby bug: https://bugs.ruby-lang.org/issues/11744
There is a known issue with the listen tests that casuses files to be
incorrectly GC'ed even when they are still in-use. The current is to
only run them in isolation to avoid randomly failing our test suite.
The bug report templates are now executed from the `ci/travis.rb` when
`GEM` contains `guides`.
I started by creating a `test` task in `guides/Rakefile` to handle this,
but since inline `gemfile` must not be executed with `bundle exec`, that
rake task would not be consistent with others. So I went back by
executing them directly from `Build`.
Use inline Gemfile dependency when reporting gem bugs
Rafael Mendonça França