Test tooling overlap (ansible-test, ansible-lint, ARI, ...)

[MarkusTeufelberger]

Is there a plan to resolve the sometimes significant overlap between official (hosted in https://github.com/ansible) tooling around static checks/lints for Ansible YAML content?

Take for example https://ansible.github.io/ansible-risk-insight/rules/R301_non_fqcn_use/ vs. https://ansible-lint.readthedocs.io/rules/fqcn/ (ansible-test does not (yet?) validate their EXAMPLES sections which would be the applicable place for a FQCN check). Relevant code: https://github.com/ansible/ansible-risk-insight/blob/main/ansible_risk_insight/rules/R301_non_fqcn_use.py vs. https://github.com/ansible/ansible-lint/blob/main/src/ansiblelint/rules/fqcn.py

I guess there might even be more tools out there that implement similar functionality (https://steampunk.si/spotter/ comes to mind), especially when it comes to style and formatting. Potential yamllint configs are shipped in ansible-lint (https://github.com/ansible/ansible-lint/blob/main/src/ansiblelint/yaml_utils.py), ansible-test (https://github.com/ansible/ansible/tree/devel/test/lib/ansible_test/_util/controller/sanity/yamllint/config), yamllint itself obviously (https://github.com/adrienverge/yamllint/tree/master/yamllint/conf) and probably also in whatever autoformatter will end up being recommended to be used for Ansible content (e.g. prettier.io).

This means there is overlap in both functionality ("detect where a module is referenced without FQCN") as well as intention ("ensure a consistent style for YAML files across the ecosystem"). Is there some effort to deduplicate code for checks like this or to unify configurations? Otherwise if could be the case that something like the "true/false" vs. "yes/no" issue in documentation comes up again (where ansible-lint insisted on one style and Ansible upstream took some convincing to move away from their stance on insisting on the other style) or that checks differ subtly (if I understand ARI correctly, it will for example not complain about missing FCQNs for ansible.builtin modules, which ironically is one of the most critical potential risks of a collection being used by default and overwriting builtins...).

[apatard]

imho, there's code duplication as long as you're sure that everyone is using all these tools, which is not the case I guess. Moreover, different way to check things means that the different tools may catch issues other may not.

In YAML case, it's even more complicated since it's not always a matter of "preferences". Newer YAML specs may deprecate stuff which were valid before. Once the YAML parsers support only newer specs, there will be no choice but to deal with that... The "true/false" thing is a variation of this. I think I remember that the file mode octal form is suffering from similar "problem".