-
Notifications
You must be signed in to change notification settings - Fork 660
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
var-naming[no-role-prefix] should not trigger on variables starting with ansible_ (builtins) #3456
Comments
@fanderchan When I modifying the built-in variable, and run ansible-lint on it the program doesn't crash for me. |
That is indeed a bug, we should just ignore any name starting with |
There is also https://docs.ansible.com/ansible/latest/reference_appendices/config.html#inject-facts-as-vars (see discussion at https://old.reddit.com/r/ansible/comments/13giahm/is_it_preferable_to_utilize_ansible/) - probably there should even be a rule that actually only allows Especially considering the comment by @sivel there:
|
This is also complicated by the fact (heh!) that |
|
I don't mainly want to express the perspective of crash, this is related to my code. I hope to fix ansible-lint to skip checking built-in variables. |
We are talking about setting variables here, not reading them as that is the only place where we check their names. Based on that, I would really be worried if someone tries to write If I am correct, this means that we have two types of behaviors: some sets for builtins should be ignores but others should trigger a new type of violation, like attempting to set |
The original issue by the way should be solved by setting that variable in the inventory (through host_vars or group_vars). Dynamically changing the Python interpreter after already launching Ansible is not something that I would recommend and unless there is a good reason for this that I am unaware of, I would agree with the linter in this case and not call this a bug/false positive. There might be other builtins that are maybe desirable(?) to be overwritten dynamically, but in general overwriting builtins sounds like something that should rarely/never be done. I agree that trying to set a builtin variable should be a new/special kind of error (maybe in a different set of rules compared to |
@MarkusTeufelberger You are right, but I do remember good use-cases from few years back where we had to dynamically set python path for some platforms because ansible-core was not able to guess it correctly. That is why I am not in a hurry to declare its use bad. |
Really dynamically instead of manually? Interesting. |
Yeah, involved using using |
You are right! My playbook needs to be compatible with many distributions. I've tested and found that some distributions automatically discover the Python interpreter as Python2, but these distributions must use Python3 to execute the yum command. Therefore, I manually set the ansible_python_interpreter after determining the system version in the task. Regardless, I believe there are scenarios where the built-in variables of Ansible need to be manually set, I just haven't encountered many of these situations. |
Clarifying a few things:
|
6.12.6 fixed this |
I don't get it. What if I want to use a temporary private key to initially connect to a new VM? I need to use |
We have a very short whitelist of vars that are safe to set. Maybe we need to add this one to that list. @sivel wdyt? |
Summary
ansible-lint reports an error requiring my role variable name to add the prefix "role_name_", but modifying the built-in variable ansible_python_interpreter causes the program to crash.
Issue Type
OS / ENVIRONMENT
STEPS TO REPRODUCE
When running ansible-lint check, the error reported:
Desired Behavior
ansible-lint should skip checking ansible built-in variables to avoid requiring prefixes and causing program errors.
Actual Behavior
ansible-lint requires role variable names to be prefixed with "role_name_", but modifying the built-in variable ansible_python_interpreter causes the program to crash.
"role_name_ansible_python_interpreter": /usr/bin/python3
Please let ansible-lint skip checking ansible built-in variable names to avoid similar issues.
The text was updated successfully, but these errors were encountered: