schema rule validates Ansible metadata files against JSON schemas. These
schemas ensure the compatibility of Ansible syntax content across versions.
schema rule is mandatory. You cannot use inline
noqa comments to
Ansible-lint validates the
schema rule before processing other rules. This
prevents unexpected syntax from triggering multiple rule violations.
Ansible-lint currently validates several schemas that are maintained in separate projects and updated independently to ansible-lint.
Report bugs related to schema in their respective repository and not in the ansible-lint project.
Maintained in the ansible-lint project:
schema[ansible-lint-config]validates ansible-lint configuration
schema[role-arg-spec]validates role argument specs which is a little bit different than the module argument spec.
schema[execution-environment]validates execution environments
schema[galaxy]validates collection metadata.
schema[inventory]validates inventory files that match
schema[meta-runtime]validates runtime information that matches
schema[meta]validates metadata for roles that match
meta/main.yml. See role-dependencies or role/metadata.py) for details.
schema[playbook]validates Ansible playbooks.
schema[requirements]validates Ansible requirements files that match
schema[tasks]validates Ansible task files that match
schema[vars]validates Ansible variables that match
Maintained in the ansible-navigator project:
schema[ansible-navigator]validates ansible-navigator configuration
meta/main.yml files, Ansible-lint requires a
property that clarifies if a role is an old standalone one or a new one,
Ansible-lint requires the
standalone key to avoid confusion and provide more
specific error messages. For example, the
meta schema will require some
properties only for standalone roles or prevent the use of some properties that
are not supported by collections.
You cannot use an empty
meta/main.yml file or use only comments in the
These errors usually look like "foo was moved to bar in 2.10" and indicate module moves between Ansible versions.