Should we have a collection linter?

[felixfontein]

Something that coexists with ansible-test sanity, and can check more conditions from https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst, for example ansible/ansible#74558 (Error if non-standard dirs exist under plugins/).

Advantage over having that (configurable in some way) in ansible-test: you don't need to use ignore.txt entries for older ansible-test versions if you are using a new plugin type that is introduced in a new ansible-core version; instead, just upgrade the linter.

Disadvantage: yet another tool to use, and someone has to write and maintain it.

[ssbarnea]

Why not reusing the ansible-lint and extending it with the functionality we need?

Yet-another-tool to maintain is a real nightmare I have, not joking.

[MarkusTeufelberger]

As I understand it, ansible-lint is mostly (only?) concerned with statically checking YAML and maaaybe jinja2 content while ansible-test is mostly about Python code and executing integration/unit/... tests and checking their result. molecule would also be a tool to do the latter and I personally would be happy to see the "run a playbook and check its results" part of ansible-test be moved there eventually so it is more clear what each tool does (and should do) best.

Many things from https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst (Checklist: https://github.com/ansible-collections/overview/blob/main/collection_checklist.md) sound like a good fit for ansible-lint rules, nearly everything there either needs a human in the loop or can be done as a static check. Some might require a bit more dynamic work (e.g. "Collections MUST not use files outside meta/, plugins/, roles/ and playbooks/ in any plugin, role, or playbook that can be called by FQCN, used from other collections, or used from user playbooks and roles. A collection must work if every file or directory is deleted from the installed collection except those four directories and their contents." might require moving these 4 directories elsewhere and running tests on this limited version again to make sure the rule is followed) which can be automated, but I wouldn't expect ansible-lint to do this.

All in all I think a combination of ansible-lint and ansible-test can already cover this use case, with likely most things covered by ansible-lint (a lot of things on that checklist are imho best practice, so I don't think there are any that wouldn't be in the default set of rules anyways, no need for a special ansible-lint --mode collection-conformance or the like).

[ssbarnea]

@MarkusTeufelberger must have read the messaging from DevTools team. Yes, soon we will introduce profiles to ansible-lint which would configure set of rules for specific purposes, like linting collections.

To answer the original question: ansible-lint is the collection linter. If it does not do something, we will fix it. In fact linting collections is no1 use-case for the linter.

To give some insights, in the future you will likely see more feature related to linting moving from ansible-test to ansible lint. Ansible-test will remain the too for unit/functional testing. As seen with molecule, the linting was deprecated and will be removed from it.

We are slowly migrating towards a more unix like philosophy where we will have one tool for each scope: ansible-lint for static, ansible-test for unittest/module testing, molecule for integration testing.

While not everything is set in stone, I do hope that this will help others makle the best future proof tool pick.

[mariolenz]

@felixfontein Please close this issue if done, or open a new forum topic and then close the issue with a pointer to the new discussion: Community-topics: Archiving the repo