playbook linting

41 views
Skip to first unread message

Jesse Keating

unread,
Feb 21, 2014, 5:22:56 PM2/21/14
to ansible...@googlegroups.com
We're growing the number of contributors, and some books are under rapid
development. I'd love to be able to put a linter to the task of linting
pull requests and yelling if something doesn't look right.

Any of you doing any kind of linting for playbook files?

-jlk

Michael DeHaan

unread,
Feb 21, 2014, 5:27:51 PM2/21/14
to ansible...@googlegroups.com
So for starters, though it's not everything:

ansible-playbook  --syntax-check exists

Part of the issue here is that it does a bit too much manual work, rather than relying on logic in the Playbook/Play classes, as it should -- which has been on the list for a little while to get more back into shared code.

I generally believe this should be a task for core ansible, not a linter, and is why for instance we added a warnings feature for deprecation and some of the common YAML errors.

(i.e. extra external things shouldn't be required, good things should be built in)

--Michael




--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/5307D1C0.1020609%40j2solutions.net.
For more options, visit https://groups.google.com/groups/opt_out.

Jesse Keating

unread,
Feb 24, 2014, 11:22:18 AM2/24/14
to ansible...@googlegroups.com
On 2/21/14, 2:27 PM, Michael DeHaan wrote:
> So for starters, though it's not everything:
>
> ansible-playbook --syntax-check exists
>
> Part of the issue here is that it does a bit too much manual work,
> rather than relying on logic in the Playbook/Play classes, as it should
> -- which has been on the list for a little while to get more back into
> shared code.
>
> I generally believe this should be a task for core ansible, not a
> linter, and is why for instance we added a warnings feature for
> deprecation and some of the common YAML errors.
>
> (i.e. extra external things shouldn't be required, good things should be
> built in)

Yeah, I'd be really happy if it was built into ansible!

We are aware of --syntax-check, and it helps, along with --list-hosts,
but that doesn't catch attempts to make use of files that don't exist.
Even that is tricky though, because you could be attempting to make use
of a /generated/ file, so there would be false warnings that would have
to be filtered out.


-jlk
Reply all
Reply to author
Forward
0 new messages