Open TheSpy0 opened 3 weeks ago
I believe the issue you're seeing, at least for the ansible.builtin.dnf
module, is due to the changes from https://github.com/ansible/ansible-lint/pull/4131. The relevant change in the PR can be seen here, where an action plugin of the same name as the module is attempted to be loaded first. Modules that have a corresponding action plugin do not have their arguments validated. I'm basing this on the following code.
It appears you are correct. I found some modules that did not have action plugins with the same name (ansible.builtin.apt
and ansible.builtin.cron
were a couple of them) and received warnings (see below) when executing ansible-lint
that there were options set that the modules did not support.
This is the intended behavior then?
Below is an example of the ansible.builtin.apt
module.
- name: Test task
ansible.builtin.apt:
name: test
sdf: stuff
state: present
WARNING Listing 2 violation(s) that are fatal
args[module]: Unsupported parameters for (basic.py) module: sdf. Supported parameters include: allow_change_held_packages, allow_downgrade, allow_unauthenticated, autoclean, autoremove, cache_valid_time, clean, deb, default_release, dpkg_options, fail_on_autoremove, force, force_apt_get, install_recommends, lock_timeout, only_upgrade, package, policy_rc_d, purge, state, update_cache, update_cache_retries, update_cache_retry_max_delay, upgrade (allow-downgrade, allow-downgrades, allow-unauthenticated, allow_downgrades, default-release, install-recommends, name, pkg, update-cache). (warning)
Summary
Incorrect module arguments no longer trigger a
args[module]
error foransible.builtin
modules when using anyansible-lint
that is version24.5.0
or higher, including the current version24.7.0
. This is not the case with the versions I've tested including24.2.3
,6.22.2
, and6.14.3
.Issue Type
OS / ENVIRONMENT
STEPS TO REPRODUCE
Run
ansible-lint <insert_playbook_name>.yml
when an incorrect module argument is present in a playbook and theansible-lint
version is>=24.5.0
. The example below uses theansible.builtin.dnf
module, but this has also been tested with theansible.builtin.package
module. Running with a non-builtin module such ascommunity.general.flatpak_remote
did trigger the error correctly.Desired Behavior
Output similar to the following should occur for
ansible.builtin
modules.Actual Behavior
Please give some details of what is happening. Include a [minimum complete verifiable example] with:
ansible-playbook --syntax-check playbook
See Gist for minimal playbook https://gist.github.com/TheSpy0/c698fbe4089723c853cb4844b3592940