Skip to content
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

False positive: hosts variable not defined #4225

Open
jrglynn2 opened this issue Jun 19, 2024 · 3 comments
Open

False positive: hosts variable not defined #4225

jrglynn2 opened this issue Jun 19, 2024 · 3 comments
Labels

Comments

@jrglynn2
Copy link

Summary

False positive for undefined variable in hosts.

Issue Type
  • Bug Report
OS / ENVIRONMENT
ansible-lint --version
ansible-lint 24.6.0 using ansible-core:2.17.1 ansible-compat:24.6.1 ruamel-yaml:0.18.6 ruamel-yaml-clib:0.2.8
  • ansible installation method: pip
STEPS TO REPRODUCE

See issue #3229 - same question.

Desired Behavior

Answer was provided - #3229 (comment) - but the answer is to set a default value for hosts, which I would never want to do.

Desired behavior is that we can set something in ansible-lint config to tell ansible-lint to ignore any undefined variables - either altogether, or specifically in the hosts: line

Actual Behavior

ansible-lint highlights error - The field 'hosts' has an invalid value, which includes an undefined variable. The error was: 'hosts_used' is undefined

This isn't an error - all my playbooks are designed to feed in a host as needed, on purpose. So, I should be able to tell Lint to ignore this error. Desired behavior is that we can set something in ansible-lint config to tell ansible-lint to ignore any undefined variables - either altogether, or specifically in the hosts: line

@AtelierSnek
Copy link

Similarly, this issue does not go away even if the undefined part has a default and is a limiting filter:

hosts: "SOME_LOADBALANCERS:&{{ zone | default('SOME_ZONE') }}"

Side note: Yes I know you can do this with --limit but this is a variable that's guaranteed to be defined in our use-case, and having to define it in two variables or two places goes against consistent behaviour.

@jrglynn2
Copy link
Author

jrglynn2 commented Nov 1, 2024

Is there any ETA on when this might be added? Thanks!

@cavcrosby
Copy link
Contributor

@jrglynn2 Hopefully PR #4393 will address this issue. It should be merged sometime soon, presuming things check out fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

4 participants