You have twenty seconds to comply. #229
Conversation
| @@ -10,4 +10,6 @@ end | |||
|
|
|||
| group :development do | |||
| gem 'github_changelog_generator', '>= 1.16.4' | |||
| # provides the rubocop config and an awesome circular dependency to boot! | |||
There was a problem hiding this comment.
🤨 Wat? CI seems happy with this…
There was a problem hiding this comment.
voxpupuli-test has a dep on facterdb. I'm not sure if this would work at all if the Gemfile was in a released version of facterdb. We all use constraint resolvers every day but does anyone actually understand them? :)
|
|
||
| inherit_gem: | ||
| voxpupuli-test: rubocop.yml | ||
|
|
There was a problem hiding this comment.
@ekohl ehat do you think about this? at the moment we only use it in modules. other gems have their own rubocop config which is isually way shorter.
There was a problem hiding this comment.
I do think our Rubocop in vp-test is intended for Puppet modules, not real Ruby code. It would be better to come up with a shared config for real gems. It also would prevent this from pulling in a LOT of unrelated code.
There was a problem hiding this comment.
I'm fairly sure that as-is is a bad idea. My goal with this PR was to simply get rubocop working and merged before the style changes bit-rot. Then additional PRs can be made as cop configuration is agreed upon. Configuring rubocop is like ordering a pizza... I was concerned that starting from scratch was going to take a long time to build consensus. I have two suggestions to resolve the circular dependency and I honestly don't have much of a preference.
A) move rubocop.yml out of voxpupuli-test: into a new gem
B) copy the current voxpupuli-test rubocop.yml into this module with minimal modifications
Are either of those acceptable solutions?
There was a problem hiding this comment.
I think those are all points I can agree with. I'm fine with either solution. My suggestion there was roughly option A and then use that gem in all Ruby projects maintained by Vox Pupuli. I'd also be happy with option B short term and option A long term. That would at least allow this to move forward and we need to align a lot of projects anyway.
There was a problem hiding this comment.
@ekohl If I copy the rubcop.yml from voxpupuli-test, would this PR be ready for merge?
jhoblitt
force-pushed
the
feature/rubocop
branch
from
1c8df69 to
5d49e38
Compare
jhoblitt
force-pushed
the
feature/rubocop
branch
2 times, most recently
from
9280568 to
e2eae81
Compare
jhoblitt
force-pushed
the
feature/rubocop
branch
from
e2eae81 to
3b5ecf2
Compare
|
Is this still relevant? Would need a rebase has merge conflicts. |
|
I think that the PMC needs to make a decision on rubocop policy for puppet vs ruby repos. |
|
We've https://github.com/voxpupuli/voxpupuli-rubocop/ which provides a rubocop config for our gems. For Puppet we've to support ancient Ruby versions that are often EoL. We don't have that requirements for most gems so I think it makes sense to maintain two rubocop configs. One for EoL Puppet Ruby and one for the rest. |
No description provided.