-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(MAINT) Rubocop updates #27
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportBase: 100.00% // Head: 100.00% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@
## master #27 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 1 1
Lines 61 24 -37
=========================================
- Hits 61 24 -37
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll note we have https://github.com/voxpupuli/puppet-lint_modulesync_configs
I'd also prefer a step where we run Rubocop first and then the regular test matrix.
.rubocop.yml
Outdated
- "**/Puppetfile" | ||
- "**/Vagrantfile" | ||
- "**/Guardfile" | ||
Layout/LineLength: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of this HUGE config. Any thoughts about reusing it like we did with our Puppet modules?
This means we can put all the rules in puppet-lint.gem and use it in every plugin. Note that you can still override everything in gems, you just set a baseline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this idea a lot. If i'm honest, I didn't even realise it was a possibility.
I guess we could sync the merge of this PR with a new release of puppet-lint.
Oh nice I'll take a look at these configs. And yes makes sense to have a rubocop job, I'll make the test matrix dependent on success. |
196c32b
to
7ad68f6
Compare
f7321a4
to
c5018d6
Compare
I'm at odds with the 2.5 bundler step right now. The test steps don't need Rubocop so we could add a Maybe I should rename the group to something like It's early so I could be missing something obvious here!! |
9d658e2
to
39c3b20
Compare
Prior to this commit the minimum Ruby version was set to 2.0. This commit bumps the minimum requirement to 2.7 and also adds gems required for rubocop.
This commit adds Rubocop configuration with the TargetRubyVersion set to 2.5.
This commit removes the following ruby versions from the test matrix: * v2.4 * v2.5 * v2.6
39c3b20
to
65a032c
Compare
@ekohl @bastelfreak I'm working towards a release for puppet-lint which will include the Rubocop rules in this PR. I'm not 100% sure on the timeline though. Could this PR go in as it is? We can inherit puppet-lints rules once it is released. |
on second thoughts it might be wise to cut the 0.4.3 release from what we already have in master as I guess this PR would be a breaking change. People may want to benefit from the array fix without having to bump to a major release. |
@ekohl I've raised this PR that adds the rubocop config to puppet-lint I'm really hoping to get 3.0 released today! |
This commit sets the minium required version of puppet-lint to v3.0.0. As of this version puppet-lints rubocop config is bundled with the gem. This means that we can now consume it in plugin projects.
This commit ensures that we inherit the rubocop configuration from puppet-lint .
eesh I bet that failure is because I'm trying to inherit .rubocop.yml. Wasn't there an issue that prevented this? |
I'm not so sure actually. Locally I don't get that error so I can't really explain it. |
I'll dig in to it a bit more later/tomorrow but it appears that the excludes are not being inherited. FWIW I don't get it locally either . |
@ekohl I managed to replicate locally this morning: bundle install --path vendor/gems
bundle exec rubocop Adding the exclude for Another interesting observation is that I'll continue to investigate, however I've been asked to look at something else today so i'll probably get back to this on Monday. |
When inheriting from a gem, the AllCops/exclude property doesn't seem to be propagated. Running rubocop with --degbug confirms that it is recognising the directive to inherit .rubocop.yml from puppet-line and rules seem to be valid. This commit adds the AllCops/Exclude containing a single value that excludes the "vendor" directory that appears when running in ci.
Had another look at this. If you run rubocop with --debug, you can see that the settings are being properly inherited from puppet-lint. However, it still seems to disregard AllCops/Exclude. I've added a new commit that adds the excludes to the local rubocop file. I wonder if this is an appropriate workaround? |
Could it be that this ancient version of Rubocop doesn't properly support it? |
ebb94fc
to
ea1b036
Compare
ea1b036
to
9399d7c
Compare
Turns out the answer to this is no (actually to my surprise)! It seems to be some sort of conflict inheriting a config file called Renaming to something arbitrary and appears to work. |
Pondering on this topic a bit.. How would you feel about referencing the baseline config from a url rather than the gem? It would mean we are not tied in to gem releases to get config updates. https://docs.rubocop.org/rubocop/configuration.html#inheriting-configuration-from-a-remote-url |
This essentially means we can't do versioning. Let's say a new major version comes out: do you version the URL? Then what's the benefit compared to using it from the gem? It also makes it harder to test out new changes IMHO. Now you can change your Gemfile to point to a local checkout ( |
Btw, I'd also consider a puppet-lint-rubocop package that has exact dependencies on Rubocop versions and the config. Then puppet-lint itself and all plugins can depend on that. It'd remove the need to sync the versions. |
It's interesting that you mention the rubocop gem as it's something I'd thought about for the modules. My main issue is that I keep coming across dependency conflicts which slows this sort of progression.. however it would be cool to isolate as much as possible.. |
For Vox Pupuli we already use this: https://github.com/voxpupuli/voxpupuli-test/blob/master/rubocop.yml |
Prior to this PR the minimum Ruby version was set to 2.0.
This PR bumps the minimum requirement to 2.7 and also adds gems required for Rubocop.
In addition it also contains fixes for files in lib and spec.
Rubocop configuration was taken from another vox project with the addition of
SuggestExtensions: false
.