Misleading errors for schema validation of meta file

[StopMotionCuber]

Summary

When having a meta yaml, the error message for validation was misleading in my case.

Issue Type

• Bug Report

Ansible and Ansible Lint details

ansible-lint 6.3.0, installed via pip

STEPS TO REPRODUCE

Have a meta file like following in a role:

galaxy_info:
  author: Author
  description: Description
  license: GPLv3
  min_ansible_version: 2.8
  platforms:
    - name: EL
      versions:
        - 7
  galaxy_tags:
    - system

Desired Behavior

Output is

schema: 7 is not one of ['5', '6', '7', '8', '9', 'all'] (schema[meta])
roles/sample_role/meta/main.yml:1  Returned errors will not include exact line numbers, but they will mention
the schema name being used as a tag, like ``playbook-schema``,
``tasks-schema``.

Actual Behavior

schema: 7 is not one of ['6.1', '7.1', '7.2', 'all'] (schema[meta])
roles/sample_role/meta/main.yml:1  Returned errors will not include exact line numbers, but they will mention
the schema name being used as a tag, like ``playbook-schema``,
``tasks-schema``.

Additional hints:

When looking at the schema file, ['6.1', '7.1', '7.2', 'all'] seems like the error was that the platform was detected to be an AIX. Obviously that is wrong and the error was that 7 was not a string. The error also hinted that "7" wouldn't have been a valid choice

[ssbarnea]

Make it a string, the 7 it complains about is an integer not a string. See python-jsonschema/jsonschema#948

[StopMotionCuber]

Ah, thanks for the info. Didn't realize that you already reported that upstream (and what the upstream project was for this issue)

[anxstj]

I still experiencing this issue with ansible-lint 6.5.2 using ansible 2.13.2, jsonschema 4.15.0

And the workaround with making the integer a string. Doesn't work anymore.

[ssbarnea]

@anxstj If you look at the entire platform entry, you will find the missing combination of platform name and version. Please do not put random comments without clear information on closed bugs as they do not help anyone.

[anxstj]

Steps to reproduce my issue:

# molecule --version
molecule 4.0.1 using python 3.10
# molecule init role acme.foo -d docker --verifier-name goss
# cd foo
# cat << EOT > meta/main.yml
---
galaxy_info:
  author: Author
  description: Description
  license: GPLv3
  min_ansible_version: 2.8.0
  platforms:
    - name: CentOS
      versions:
        - '7'
  galaxy_tags:
    - system
EOT
# ansible-lint .
WARNING  Listing 1 violation(s) that are fatal
schema: {'name': 'CentOS', 'versions': ['7']} is not valid under any of the given schemas (schema[meta])
meta/main.yml:1  Returned errors will not include exact line numbers, but they will mention
the schema name being used as a tag, like ``playbook-schema``,
``tasks-schema``.

This rule is not skippable and stops further processing of the file.

Schema bugs should be reported towards (https://github.com/ansible/schemas) project instead of ansible-lint.

If incorrect schema was picked, you might want to either:

* move the file to standard location, so its file is detected correctly.
* use ``kinds:`` option in linter config to help it pick correct file type.


You can skip specific rules or tags by adding them to your configuration file:
# .config/ansible-lint.yml
warn_list:  # or 'skip_list' to silence them completely
  - experimental  # all rules tagged as experimental

Finished with 0 failure(s), 1 warning(s) on 6 files.

So, it seems that "CentOS" is not defined in ansible/schemas. I guess I need to patch ansiblelint/schemas/meta.json to support it. Sorry for the noise.

[ssbarnea]

That is because everyone use "EL" for it, which covers both RHEL and CentOS. Look at https://github.com/ansible/schemas/blob/main/f/ansible-meta.json#L298-L308

If you search on galaxy, you will not find one collection supporting "CentOS" but lots using "EL". It is bit confusing but I do not know how the schema can help in this area.

Maybe we can update the description field to tell people to use "EL" if they want to use centos or rhel.

[synergiator]

Observing now same meta linting error with Debian platform spec.

  platforms:
    - name: Debian
      versions:
        - "11"

Error:

schema[meta]: $.galaxy_info.platforms[0].versions[0] '11' is not one of ['6.1', '7.1', '7.2', 'all']. 
See https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html#using-role-dependencies
roles/keepalived/meta/main.yml:1  Returned errors will not include exact line numbers, but they will mention
the schema name being used as a tag, like ``schema[playbook]``,
``schema[tasks]``.

This rule is not skippable and stops further processing of the file.

If incorrect schema was picked, you might want to either:

* move the file to standard location, so its file is detected correctly.
* use ``kinds:`` option in linter config to help it pick correct file type.

• linked guide seems to be not relevant for this context?
• in the old source code it says, "for available platforms and versions, visit this spec", but it is no more available?
• Also the official meta spec does not tell much on this.

Used version/OS:

• Debian 12 Bookworm
• ansible-lint 6.22.1 using ansible-core:2.16.0 ansible-compat:4.1.10 ruamel-yaml:0.18.5 ruamel-yaml-clib:0.2.7
• jsonschema 4.10.3

@ssbarnea any comments?