Closed SHinGo-Koba closed 8 months ago
@SHinGo-Koba my advice is that this should be avoided and to use bundler instead which will handle the ordering. With a rubocop
gem group, and this workflow setup, should avoid that issue.
env:
BUNDLE_ONLY: rubocop
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
# ...
bundler-cache: true
- uses: reviewdog/action-rubocop@v2
with:
# ...
skip_install: true
use_bundler: true
If this works for you, I would welcome a PR to update the README with a detailed example and downgrade the existing example since this should be the preferred setup. Thank you.
@javierjulio Thank you for your reply!
I see. I didn't notice that option but I think it'll be good solution to deal with the issue. After checking it, I'll create a PR to update the example with mentioning this point.
@SHinGo-Koba you’re welcome. In this comment https://github.com/reviewdog/action-rubocop/issues/83#issuecomment-1942014445 I have an example of the gem group I referred too since I didn’t include it here.
@javierjulio I tried and confirmed it works well. Thank you so much again! Next, I'll create a PR and let you know if it is ready.
@SHinGo-Koba that's great news! You're very welcome. Ok sounds good, thank you.
Since
rubocop-rspec
requiresrubocop-factory_bot
andrubocop-capybara
,rubocop-factory_bot
andrubocop-capybara
installation version from Gemfile does not work if you setrubocop-factory_bot:gemfile
orrubocop-capybara:gemfile
afterrubocop-rspec
in optionrubocop_extensions
.This might cause unexpected rubocop violations due to new rules in latest gem version.
To avoid this at this point, we need to take the definition order of gems into account. But I think it would be better not to depend on definition order since we can not notice easily why ci fails suddenly.