Learning puppet by my self, I found useful to avoid common mistakes in my modules/manifests. No body knows puppet in my current position, so it’s hard get reviews of my work. I started looking at automated codereview/lint and stumble upon puppet-lint. In his last pre release, the tool implemented autofix of common errors. Let’s see how to measure my progress and learn from my mistakes 😉
First step, to gain visibility, I’ve plugged puppet-lint in our jenkins instance. Setting up jenkins to collect puppet-lint warning. Small modification for me, I don’t abort the build to enable warnings collection with this modified rake task.
Install the pre-release of puppet-lint.
gem install --pre puppet-lint -v 0.4.0.pre1
Uninstall the previous version
gem uninstall puppet-lint Select gem to uninstall: 1. puppet-lint-0.3.2 2. puppet-lint-0.4.0.pre1 3. All versions > 1 Successfully uninstalled puppet-lint-0.3.2
Launch puppet-lint with auto-fix options.
ERROR: two-space soft tabs not used on line 15 ERROR: two-space soft tabs not used on line 19 FIXED: unquoted resource title on line 14 WARNING: line has more than 80 characters on line 5 WARNING: line has more than 80 characters on line 6
Double check the changes, launch rspecs, and a vagrant provision than commit
autofix with puppet-lint 8 files changed, 82 insertions(+), 63 deletions(-)
Lets see the jenkins statistics.
Thanks puppet-lint ! Now it’s time to fix the trivial one (two-space soft tabs) and less trivial one (“foo::bar not documented” , “class inheriting from params class” ,“define defined inside a class”,… ) 😉
What I’ve learned with this experiment:
— if you don’t show your errors, you are not really pushed to fix them
— it takes time to setup these quality tools, but it worth it.
— you are overloaded by warnings, fixing the stupid one automatically and fixing the easy one make you more optimist/confident to attack the harder one.
— it’s easier to fix when there are fresh in your mind