Set working directory to file's parent before invoking `ansible-lint` to better find `.ansible-lint` files

Problem

Currently, only the .ansble-lint file in the root of the repo seems to affect this extension's ansible-lint. I haven't confirmed it but I am assuming this is because the extension invokes ansible-lint with the full path to the file, from the root of the project as its working directory.

This makes it impossible to define .ansible-lint files in deeper directories to apply differently scoped rules to those directories.

Solution

ansible-lint will look in the working directory for an .ansible-lint file, and if not found will keep looking in parent directories until one is found or it reaches the root of the git repository (https://ansible-lint.readthedocs.io/en/latest/configuring.html#configuration-file):

When configuration file is not found in current directory, the tool will try to look for one in parent directories but it will not go outside current git repository.

So I'm proposing that this extension change the current working directory to that of the file to be linted, and then invoke ansible-lint with just the file name.

For example consider the file to be linted is roles/my_role/tasks/main.yml, the extension would set the cwd to roles/my_role/tasks and invoke ansible-lint main.yml.

That would allow an .ansible-lint file anywhere in the parent(s) to be located, like if there were one in /my_role/ or even in /roles/ for example.

Alternatives

The extension could offer settings instead, like a mapping of directories to specific rules files maybe? But it seems a pain to maintain, and less elegant in the long run.

If the proposed solution is implemented that could also be a configurable setting, in case there are users who want to always use the file in the root (or always use a specific file).

Additional context

One practical reason for wanting this: as a collection maintainer, I want to apply rules to the roles in tests/integration/targets that are different (less strict) than the rules for roles/ which will be published and used by end-users.

I've actually tried the solution you propose - it is exactly how the extension used to work earlier in the development phase. Unfortunately, it made the linter oblivious to any configuration in ansible.cfg, which it needs to function correctly in some cases. This is why I switched to invoking the linter from the root of the workspace - where the Ansible configuration file can usually be found (ansible-lint does not have an option to provide path to the Ansible configuration file).

To cover all scenarios, I propose that the extension mimics behavior of ansible-lint, finds that configuration file going up the directory structure, and if found, feeds it to the linter using the -c option.

I've actually tried the solution you propose - it is exactly how the extension used to work earlier in the development phase. Unfortunately, it made the linter oblivious to any configuration in ansible.cfg, which it needs to function correctly in some cases. This is why I switched to invoking the linter from the root of the workspace - where the Ansible configuration file can usually be found (ansible-lint does not have an option to provide path to the Ansible configuration file).

I see, that makes sense. Didn't even think of that. Thanks for the explanation!

To cover all scenarios, I propose that the extension mimics behavior of ansible-lint, finds that configuration file going up the directory structure, and if found, feeds it to the linter using the -c option.

That seems like a workable solution to me (for my purposes at least).

ansible.cfg files can also be located in deeper directories; unlike ansible-lint, I don't believe the ansible[-*] commands do any searching other than the CWD though. Of course, it's impossible to know from file structure alone how anyone intends to run these commands so it's certainly difficult offer a perfect solution.

The extension could implement config options that control different methods of searching, for both the ansible.cfg and .ansible-lint files. A little more complex, but also more flexible.

For example, I have some Ansible repos that have a few sub-directories that are intended to be like their own little Ansible islands, with their own config and sometimes inventory (I see this pattern with Packer builds a lot).

For my immediate use case though (a collection repo) the proposal to mimic .ansible-lint searching works; maybe a future enhancement could incorporate more options for ansible.cfg searching /loading too.

Thanks once again!

I'm releasing a new version in which discovery of the .ansible-lint file is aligned with the behavior of the ansible-lint command invoked from the directory containing the investigated file. This change was definitely necessary, just following the principle of least surprise, as users might already be accustomed to that linter behavior.

As for a setting for pointing to Ansible configuration. It is worth considering, but for the moment it is impossible to point the linter to that configuration. AFAIK, not even Ansible Tower allows configuring that - it just uses ansible.cfg at the top of the repo.

Finally, a solution/workaround could be switching to VSCode's multi-root workspaces where each directory requiring its own configuration would be a root folder of the workspace.

tomaciazek / vscode-ansible