document ansible-review vs ansible-lint

[ssbarnea]

I think that the relationship between ansible-review and ansible-lint should be explained in the main README, making clear when you may/should want one use or another.

[dmsimard]

+1

[willthames]

Does this need anything more than the first couple of paragraphs from http://willthames.github.io/2016/06/28/announcing-ansible-review.html

If not I'll just add that as an introduction to the README

[dmsimard]

I'm not sure ? From the perspective of a new user I guess it makes it sound like it's a smarter and more flexible ansible-lint ? So why have ansible-lint in the first place ?

[willthames]

"Why have ansible-lint in the first place" ignores history somewhat. It was around for a good few years before ansible-review. But perhaps you meant "Why continue to provide ansible-lint"

ansible-lint is used under the hood by ansible-review. People can (and do) use ansible-lint for problem finding. I could reword ansible-lint's documentation to make it clearer that these days I suggest it's designed more as a library than a tool, and improve ansible-review's documentation to make its purpose clearer. But I guess that's what this issue is about :)

[retr0h]

"Why have ansible-lint in the first place" ignores history somewhat. It was around for a good few years before ansible-review. But perhaps you meant "Why continue to provide ansible-lint"

Seems as though ansible-review should simply replace ansible-lint for users wishing to lint and/or validate their role follows best practices.

I'm looking to incorporate ansible-review into Molecule, and it feels I could simply swap ansible-lint for ansible-review vs having Molecule execute ansible-lint then ansible-review as part of the Molecule lint workflow.

Is this a reasonable assumption?

P.S. Sure would be cool if RH would incorporate these linting tools into the core project in addition to Molecule as ansible-test :)

[dhartford]

As I'm learning the two, I think it is important to add some type of clarification statement to both projects, explaining each and how they relate to each other.

Ansible-lint

• Syntax checking
• Rule checking (including adding your own rules)
• Integrates into IDE's (Atom.io and Sublime for example), often on a per-file review basis.

Ansible Review:

• If you want to have automated code reviews outside of an IDE.
• Focuses on change-only review of the entire playbook/role across multiple files.
• 'Macro review of the whole' that builds on the micro-detail analysis of ansible-lint.

Something to kick around from, at least as a new user trying to understand them point of view (which may be way off base ;-) ).

[wilmardo]

I'm looking to incorporate ansible-review into Molecule, and it feels I could simply swap ansible-lint for ansible-review vs having Molecule execute ansible-lint then ansible-review as part of the Molecule lint workflow.

I am the author of the issue mentioned here.

The main reason why I opened the issue over at molecule is because I am looking for a way to enforce some coding standards. Most importantly a rule to enforce the native YAML syntax over the key=value syntax. At ansible-lint a PR was opened for a rule like this and the author clearly states that ansible-lint is no place for it and I should look into ansible-review.

I'm looking to incorporate ansible-review into Molecule, and it feels I could simply swap ansible-lint for ansible-review vs having Molecule execute ansible-lint then ansible-review as part of the Molecule lint workflow.

Is this a reasonable assumption?

I think it is since ansible-review contains a hook to ansible-lint so that keeps working, but on top of that more advanced rules become possible.

Would be cool if @willthames can chime in? 👍

[willthames]

@wilmardo I think that for your use case, ansible-review should work well as an alternative to ansible-lint - it's just a matter of coming up with the standards.py that you want to use.

My main problem with extending ansible-lint further is that there is no one true way for all, and ansible-review provides a way to use the included rules to enforce the standards and best practices your organisation cares about. Perhaps I've just become less strongly opinionated after working with multiple teams with different practices neither of whom were arguably wrong, but wanted to maintain consistency within themselves (which means I still need to make yaml indentation rules more customisable!)

[willthames]

In the general response to this ticket, yes, I should definitely write some stronger documentation about support policies and purposes.

In the main, ansible-lint should be considered bug fix only (I'll keep supporting new ansible versions) - there won't be new rules but broken existing rules will be addresed. New rules should be added to ansible-review for people to pick and choose for their projects.

All this takes time, and I haven't allocated much for this kind of tidy up (although it would save me time having to write the same answers again and again!)

[rrey]

Hello,

I am a simple user of ansible-lint, I never tried to enter in the code to see if I could write my own rules.
I just discovered ansible-review, and played with it by writing some of the best practices we have in the company.

I read this thread and I understand the relation between ansible-lint and ansible-review, but I don't understand what led to a new project ?
What is the limitation in ansible-lint that made @willthames create ansible-review ? What ansible-review now enables that was impossible with ansible-lint ?

Feel free to redirect me to a blog post or an issue that would answer my question.

[willthames]

The main difference is that ansible-review is designed for code reviews and is designed to be a little more configurable (there are fewer constraints on the kinds of resources that ansible-review works with). The ansible-lint project has moved forward a lot since then, and there is probably less clear difference these days.

In the main:

• ansible-review can work on just diffs, and only report issues on parts of the code that change
• ansible-review can produce warnings, not just errors (I think ansible-lint can do this too now)
• ansible-lint rules run after some parsing and normalisation of the yaml - this means that checks like tasks are in yaml form not key=value form are much harder to check (ansible-review can do this check before the normalisation)
• it's a lot easier to configure what rules are active in ansible-review (again, this has changed as there is now a configuration file for ansible-lint, but that was much harder three years ago when I wrote ansible-review)