Open mattstratton opened 7 years ago
I second the idea of switching to cookstyle. If cookstyle is the preferred method of linting cookbooks and is the defacto standard, why wouldn't it be the standard in delivery? (or anywhere else for that matter)
I'm working on a PR for this, and wonder about two possible implementations (I don't think we want to just immediately cut over, because it's possible that someone has older builders that don't have cookstyle
installed)
These are the two options as I see them:
cookstyle
is installed, run cookstyle
instead of rubocop
. Period.config.json
to over-ride and enable cookstyle
instead of rubocop
, which makes using cookstyle
an opt-in.I am more in favor of option 1, as it should be the default. Perhaps actually there is a Secret Option 3, which would be this:
If cookstyle
is installed, run it. Unless enable_rubocop
is set in the config.json
. That way if someone really wants to use rubocop
they can. This will also not break things for older builders.
It looks like cookstyle
was added to ChefDK in v0.14 (2016-05-17).
Since that was quite some time ago, I think that it's fairly safe to go with option 1. I have a fork where if cookstyle
is installed, it will run cookstyle tests in lint. If not, it will run rubocop.
I have not been able to yet test it on a builder with an older version of ChefDK that does not have cookstyle though.
I could happily submit the PR to make this change, but wanted to bring it up for discussion.
The current
chef generate
in chefdk results in a cookbook that fails rubocop (and therefore these lint tests). Is there any reason to not switch tocookstyle
for the lint tests?