Add rule for variable naming

[ssbarnea]

Originally proposed by @ansiblejunky in #1513

As any new rule, that is initially introduced as experimental, which makes it only raise warnings and not errors.

[ssbarnea]

@ansiblejunky @MarkusTeufelberger I am unable to find any variable name that passed syntax-check which means this rule does not make any sense, as any invalid variable name would be observed by the syntax check.

Unless someone can come up with at least one value that does not produce syntax-check failure, I will have to drop the idea this PR.

[ansiblejunky]

@ssbarnea I'm not sure I understand completely. The ansible syntax checker will detect "invalid" variable names, but this naming standards rule is more intended for detecting variables that do not comply with "good standards". So while the ansible syntax checker is good, it's not good enough for ensuring good practices with regards to naming your variables. For example, the variable "MyVariable" is acceptable by the ansible syntax checker, however this is a poorly named variable and would/should fail from this lint rule. It should be "my_variable" or at least all in lowercase. This is just one example. The rule detects this problem in various areas where customers/users often make "lazy" variable names, such as registering variables and set_facts and so on.

Here is what the syntax checker looks for:
https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#creating-valid-variable-names

However, the syntax checker is not checking upper/lowercase mixed variable names. The value-add from this lint rule is handling mixed cases but also looking for this on set_fact, on register, etc, etc.

I hope this helps.

[ssbarnea]

@ansiblejunky AFAIK, MyVariable would pass in its current form. Do you want to propose a rule that checks for the ^[a-z0-9_]*$ pattern and allows user to customize the pattern in config file?

I know that a previous revision had that regex, but current code checks only for what Ansible allows nothing else.

I am not against a lowercase pattern, but I am afraid of how much resent it could create among some users. I bet some uses ALL_CAPS in some places. Still, if it passed our eco pipeline I would probably not block it, especially as user could disable or neuter the rule.

[ansiblejunky]

@ssbarnea I didn't know the original regex has changed. That makes sense as to why it appears to no longer bring any value-add. My original code and intentions were to have this as an optional rule that people can use to apply this... and if possible, yes, to customize the regex would be slick.

[ansiblejunky]

I suppose the question is, whether ansible-lint checks good practices, or whether it checks what is "valid" by ansible documentation. If the former, then this rule is useful. If the latter, then we have to revert to only what the syntax checker looks for. I know that in various customer implementations this custom lint rule has helped keep YAML code clean and readable, so it's brought a lot of value. However, whether it should be added to ansible-lint repo is the question.

Perhaps if the rule defaults to the regex that checks only what the syntax checker looks for, and then we provide an example regex to additionally check for mixed case?

[MarkusTeufelberger]

Is it possible to hand a regex pattern to a rule and have that enforced instead? Then the current one (r"^[a-z_][a-z0-9_]*$") would be the default one but someone who is really into CAPITAL_LETTERS can use their own instead.

[ssbarnea]

Is it possible to hand a regex pattern to a rule and have that enforced instead? Then the current one (r"^[a-z_][a-z0-9_]*$") would be the default one but someone who is really into CAPITAL_LETTERS can use their own instead.

There is not need to "pass" the custom pattern, that is loaded from .ansible-lint config file when found. Shortly, it already allows users to define their own patterns instead of disabling the rule.

[ssbarnea]

BTW, i removed the Codacy, too much false-positives for this project, it appears to be clueless about what we configured within the project.