The puppet-lint –fix effect

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.

puppet-lint effect

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

About these ads

, ,

  1. #1 by spuder on January 24, 2014 - 7:52 pm

    Thanks for sharing.

    The puppet auto-fix feature isn’t well documented. How do you start puppet-lint with auto-fix?

  2. #3 by Tommy McNeely on February 5, 2014 - 6:10 pm

    The “class inheriting from params class” is “OK” as long as you are using Puppet 2.7 or newer. I think the style guide needs a new revision to deprecate that warning, but for now, puppet-lint does have a “–no-class_inherits_from_params_class-check” option to shut that part up. ;)

    Another good option to use is “–with-filename” which prepends the filename to the errors so you can tell what file the error is in.

    I haven’t tried the auto-fix yet, thanks for the post.

  1. The puppet-lint --fix effect | DevOps in the En...

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: