-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
document ansible-review vs ansible-lint #31
Comments
+1 |
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 |
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 ? |
"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 :) |
Seems as though I'm looking to incorporate 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 |
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
Ansible Review:
Something to kick around from, at least as a new user trying to understand them point of view (which may be way off base ;-) ). |
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
I think it is since Would be cool if @willthames can chime in? 👍 |
@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!) |
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!) |
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 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 ? Feel free to redirect me to a blog post or an issue that would answer my question. |
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:
|
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.
The text was updated successfully, but these errors were encountered: