ansible-examples should adhere to the standards of the ansible-linter

[RayJin2000]

I believe that Ansible examples should adhere to the standards of the Ansible linter.

Arguments in favor:

• Consistency and maintainability: Linting ensures that examples are consistent in style and formatting, which makes them easier to read and maintain.
• Readability: Linting can help to improve the readability of examples by identifying and fixing common errors, such as missing indentation or incorrect syntax.
• Accuracy: Linting can help to ensure that examples are accurate and up-to-date by identifying and fixing errors in the code.

Benefits:

• Improved user experience: Users will have a better experience when using Ansible examples if they are consistent, readable, and accurate.
• Reduced errors: Linting can help to reduce the number of errors in Ansible examples, which will improve the quality of the documentation.
• Increased confidence: Users will have more confidence in Ansible examples if they know that they have been linted and are therefore more likely to be accurate.

Conclusion:

I believe that the benefits of linting Ansible examples outweigh the costs. I encourage the Ansible community to adopt a linting standard for examples and to lint all examples before they are published.

[webknjaz]

outweigh the costs

Which costs have you considered exactly? Could you enumerate? The linter is pretty opinionated and only represents someone's opinion that might not be a good fit for others at all. A lot of things there are subjective and controversial, which is why the core team is not in business of forcing people to style their content one way or another. I don't believe that formatting for the sake of formatting is such a good idea universally. Some bits might be useful, others might be harmful.

Have you generated this with ChatGPT, by the way?

[webknjaz]

This is also a YAML sequence, for example. And it's not indented like the rest of things, which is inconsistent. Ideally, there shouldn't be unnecessary indentation without a good reason.

[RayJin2000]

I dont get your point here. This yaml file is indented like all other yaml files.

[webknjaz]

Why use snake_case for handlers? They aren't Python identifiers. It'd be confusing.

[webknjaz]

I know a lot of people would argue that lowercase is more natural. Like the original authors thought, apparently.

[webknjaz]

Final bit of advice: ask before starting big efforts. Also, I doubt anyone would be able to find time to verify correctness of such a huge change.

[RayJin2000]

Hi,

At first i only use Ai for translation an better readability.

I thought the ansible-lint rules where some kind of standard of the ansible community. If there are rules that are controversial, which rules should be used here? Can we create an .ansible-lint file that meets the basic needs?

I would be delighted if we could at least implement the following rules:

• command-instead-of-shell
• command-instead-of-module
• deprecated-local-action
• fqcn
• key-order
• no-free-form
• no-jinja-when
• yaml
• empty-string-compare
• deprecated-local-action
• risky-file-permissions

I see problems with Rules like:

• name: Writing all task names with a captial letter can be problematic with handlers, because they are case sensitive thats why i used snake case on listen.
• all prefix / name and meta rules

Some Examples are so old and ugly that it would be nice to remove them like mongodb.

I am willing to withdraw my large PR and create several small ones that are easier to review, if we can agree on a set of rules.

[webknjaz]

I thought the ansible-lint rules where some kind of standard of the ansible community. If there are rules that are controversial, which rules should be used here? Can we create an .ansible-lint file that meets the basic needs?

There's a difference between the community and the core team. The core team doesn't want to put up many constraints for people, keeping Ansible as flexible as possible. So from our perspective, you can structure it however you want. The community, OTOH, is a bunch of diverse folks with their own opinions. They may even contradict each other. If you want to follow those rules and use the linter — do it, as long as it works for you. I don't think we'll ever be forcing anybody to follow preset rules. Some of them, though, can catch human errors and are not watching your style. So those are useful regardless.
I personally don't use lint and the yamllint config it has by default differs from what I prefer.

I don't think anybody maintains this repository actively so please view it as historic. It has examples of starting points that you'd be modifying for yourself but that's about it.

I can't tell you which rules to follow because (1) that would be my personal opinion and (2) it requires substantial time investment to inspect each. I used to contribute to ansible-lint but I've been out-of-loop for far too long.

So yes, those rules can be a standard if you adopt it. Or they can be a reference that you can look up to. However, reformatting old repos just for the sake of it is not something worth spending time on. If you want to contribute here, you'd need to find somebody willing to work with you long enough to inspect every proposed change and having access here, of course.