ansible-lint not testing all files within ansible role structure

[ansiblejunky]

Summary

Using ansible-lint . command to lint the files within my Ansible Role structure I assume it will test all files within that structure. However it only reports issues in my tasks/main.yml file and not within any other folder (handlers/main.yml, etc). For example, it reports the error [502] All tasks should be named in my tasks/main.yml but I have the same problem in the task defined in handlers/main.yml but this is not reported as an issue.
In fact, when I run ansible-lint handlers/main.yml it just comes back with nothing reported... silence.
I tried using Python 3.8.x and Python 2.7.x and I am using a fresh pyenv virtualenv with fresh installed ansible-lint 4.2.0. I have also tested against the latest pre-release and same results.

Issue Type

• Bug Report

Ansible and Ansible Lint details

ansible --version
ansible 2.9.11
ansible-lint --version
ansible-lint 4.2.0

• ansible installation method: pyenv and pip virtualenv
• ansible-lint installation method: pyenv and pip virtualenv

OS / ENVIRONMENT

MacBook Pro laptop

STEPS TO REPRODUCE

pyenv install 3.8.2
pyenv virtualenv 3.8.2 ansible-lint
pyenv activate ansible-lint
pip install ansible-lint
ansible-lint handlers/main.yml

handlers/main.yml

---
# handlers
- debug: var=inventory_hostname

Desired Behaviour

ansible-lint should be able to check all errors within all of my yml files in the Ansible Role structure.

Actual Behaviour

ansible-lint only tests rules against tasks/main.yml and nothing else it seems... not even other tasks files within the tasks folder!

[ansiblejunky]

Ok, I see what the problem is... the rule that requires all tasks to be named, seems to have a piece of hidden code that ignores some specific tasks... hence why it didn't complain about my handlers/main.yml file.

    _nameless_tasks = ['meta', 'debug', 'include_role', 'import_role',
                       'include_tasks', 'import_tasks']

I would prefer that rules can be defined where we can override this stuff in the ansible-lint config file somehow.
Also would like the -v verbose mode to tell me what files it's linting. It does this with v4.2.0 but seems not with the pre-released versions.

[ssbarnea]

I will close this because is not really a bug and once #950 is merged users will no longer be confused about what is linted.

The idea is that when arguments passed to the linter can be only playbooks and role directories -- task/var files are not supported and due to historical reasons, these were just ignored.

Newer versions will raise an error if an unacceptable file is passed to them, avoiding false positive results. When run in auto-detection mode, the linter will use its heuristic logic to determine which files are playbooks, vars, tasks, roles, requirements, meta or unmanaged (not ansible related).

[ansiblejunky]

@ssbarnea So ansible-lint will start to be able to detect all types of Ansible files with the 950 PR ? I noticed it wasn't detecting all file types (vars, defaults) and incorrectly detecting task files as playbooks. It would be great to have it properly detect all of these and pass it on to the Runner so that we can create various rules for these file types.

I would also love if we can move some of the rules/functionality that ansible-review provides and bring it into ansible-lint. It does a good job of detecting different file types and allowing for custom rules on those types. For example, indentation in YAML file is done with a rule but this is difficult to implement in ansible-lint since it doesn't have the ability to test more than 1 line at a time in a file (since its not using the matchtask() or matchplay() - just the match().

Additionally, in reference to the rule "TaskHasNameRule.py" it would be good to allow rules to have overriding options that can be added into the config file so anyone can customize these things without having to change the python code or discover later that it behaves a specific way. Do we have a PR for that already?

[ssbarnea]

Yes, there are some PRs open related to it. I cannot guarantee that detection will be perfect from start but we can improve it, especially as now we do not allow any change to be made without being covered by tests.

I will be more than happy to see you starting to propose new changes. Do not forget to state your interest on #815 in order to receive an invitation.

Regarding yamlint, I raised #953 -- my mistake that I did not raise it at the same time as the reddit topic.