Open marcandre-larochelle-bell opened 3 weeks ago
filename
was a field for the MatchError
dataclass
at one point and only was recently removed from it when looking at https://github.com/ansible/ansible-lint/pull/4202. I was also able to reproduce this on the main
branch by running the following below.
mkdir -p "./vars/test"
cat << _EOF_ > "./vars/test/foo.yml"
---
CamelCaseIsBad: foo
ALL_CAPS_ARE_BAD_TOO: foo
_EOF_
cat << _EOF_ > "./vars/test/bar.yml"
---
CamelCaseIsBad: bar
ALL_CAPS_ARE_BAD_TOO: bar
_EOF_
ansible-lint --offline "./vars/test"
That said, when running the following in addition, this issue seems to disappear.
cat << _EOF_ > "./vars/test/bar.yml"
---
AnotherCamelCaseIsBad: bar
ANOTHER_ALL_CAPS_ARE_BAD_TOO: bar
_EOF_
ansible-lint --offline "./vars/test"
@cavcrosby for the 2nd case you highlighted, it has to be exactly the same rule "description" being broken (which in the case of var naming requires to have the same variable name), otherwise the hash calculated will be different (the only thing not taking into account for the hash right now that we noticed was the filename, which causes the conflict between hashes if there are 2 rules broken with the same description, at the same line number, but in different files).
Ahh, I see what you mean. I'll look into opening a PR for this sometime soon.
Summary
Rule breaks with the same exact message and line number, but different filename are missing due to a hash collision.
Issue Type
OS / ENVIRONMENT
ansible-lint version 24.7.0
STEPS TO REPRODUCE
The MatchError data class has the
unsafe_hash=True
, which generates automatically a hash function based on the members of the class, however the fieldfilename
is non-existent (not defined) in thedataclass
, it is added at a later stage (see: var_naming.py#L204) and then all the errors are added to a set (see: runner.py#L682). Due to thefilename
member being non-existent at the class definition, the hash function does not take into account thefilename
and cause collisions if you have the same exact rule break in another file at the same line number.Desired Behavior
The same rule break happening in a different file on the same line number should be recorded properly as different rule break.
Actual Behavior
Simplified code example of the reproducible issue we are experiencing:
Potential fix: