ansible
Excluded files are not really excluded
Summary
We are using git-crypt for secret management in our repository. Because of that, we have .yml files, that look like binary files, when the repo is locked. To make ansible-lint happy, we have defined a skip list for that in the ansible-lint config file:
exclude_paths:
- ../**/secret*.y*ml
Since ansible-lint 6.5.0 we get unicode decode errors again, although ansible-lint says it skips these files.:
[...]
DEBUG Excluded roles/myrole/defaults/main/secrets.yml (vars)
Traceback (most recent call last):
File "/Users/mathias/.pyenv/versions/ndcloud-ansible/bin/ansible-lint", line 8, in <module>
sys.exit(_run_cli_entrypoint())
File "/Users/mathias/.pyenv/versions/3.9.7/envs/ndcloud-ansible/lib/python3.9/site-packages/ansiblelint/__main__.py", line 281, in _run_cli_entrypoint
sys.exit(main(sys.argv))
File "/Users/mathias/.pyenv/versions/3.9.7/envs/ndcloud-ansible/lib/python3.9/site-packages/ansiblelint/__main__.py", line 198, in main
result = _get_matches(rules, options)
File "/Users/mathias/.pyenv/versions/3.9.7/envs/ndcloud-ansible/lib/python3.9/site-packages/ansiblelint/runner.py", line 221, in _get_matches
matches.extend(runner.run())
File "/Users/mathias/.pyenv/versions/3.9.7/envs/ndcloud-ansible/lib/python3.9/site-packages/ansiblelint/runner.py", line 120, in run
lintable.data
File "/Users/mathias/.pyenv/versions/3.9.7/envs/ndcloud-ansible/lib/python3.9/site-packages/ansiblelint/file_utils.py", line 292, in data
self._data = parse_yaml_linenumbers(self)
File "/Users/mathias/.pyenv/versions/3.9.7/envs/ndcloud-ansible/lib/python3.9/site-packages/ansiblelint/utils.py", line 750, in parse_yaml_linenumbers
loader = AnsibleLoader(lintable.content, **kwargs)
File "/Users/mathias/.pyenv/versions/3.9.7/envs/ndcloud-ansible/lib/python3.9/site-packages/ansiblelint/file_utils.py", line 218, in content
self._populate_content_cache_from_disk()
File "/Users/mathias/.pyenv/versions/3.9.7/envs/ndcloud-ansible/lib/python3.9/site-packages/ansiblelint/file_utils.py", line 210, in _populate_content_cache_from_disk
self._content = self.path.resolve().read_text(encoding="utf-8")
File "/Users/mathias/.pyenv/versions/3.9.7/lib/python3.9/pathlib.py", line 1267, in read_text
return f.read()
File "/Users/mathias/.pyenv/versions/3.9.7/lib/python3.9/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe6 in position 13: invalid continuation byte
Issue Type
- Bug Report
Ansible Lint details
ansible-lint --version
WARNING: PATH altered to include /Users/mathias/.pyenv/versions/3.9.7/envs/ndcloud-ansible/bin
ansible-lint 6.5.2 using ansible 2.12.4
- ansible-lint installation method: pip
OS / ENVIRONMENT
OS: MacOS
STEPS TO REPRODUCE
- Install ansible-lint >= 6.5.0
- put a binary in your path
- add binary to exclude list
- run ansible-lint
ansible-lint will fail with a UnicodeDecodeError on this file
Desired Behavior
ansible-lint fully ignores this file
Actual Behavior
ansible-lint tries to parse this file and throws an UnicodeDecodeError Exception
I experience the same issue (ansible-lint 6.5.2 on linux).
Yaml files in the exluded paths are stilled parsed and may fail parsing.
Experiencing the same issue, though in a more general sense than OP described. Using ansible-lint 6.5.2 on Linux. All methods of excluding paths or files seems to simply not be happening.
Out of curiosity, is any of you using .config/ansible-lint.yml location instead of the older .ansible-lint file? If true, that is likely just a duplicate of https://github.com/ansible/ansible-lint/issues/2429
@ssbarnea I'm using the older .ansible-lint. Of note, I'm seeing this exclude_paths issue both in .ansible-lint and via command-line --exclude option.
@ssbarnea Yes, I'm using .config/ansible-lint.yml, but as you can see in the debug output of my initial comment the file is honored and ansible-lint says: Excluded roles/myrole/defaults/main/secrets.yml.
@mnohrthern Just try to move the config file and see if that is fixing your problem. Another option is to run using the version from main branch and see if you can still get the error. Based on this I will know if the change I merged yesterday also fixed this bug.
Output of relative paths is not always safe to trust, as they might relative to something else than what you expect.
@ssbarnea At least my issue seems to be fixed with the latest version 6.7.0 (without changing anything to the config file). So from my side we can close the issue. Thanks for fixing!