Platforms in meta/main.yml giving false positive

[minsis]

Summary

In a roles meta/main.yml file under galaxy_info.platform versions is not linting correctly. Looking at the schema it seems no matter what you're listing under the platform key it's always matching the first item in the schema list.

➜  ansible-lint roles/agent_client_collector/meta/main.yml
WARNING  Found incompatible custom yamllint configuration (.yamllint), please either remove the file or edit it to comply with:
  - comments.min-spaces-from-content must be 1
  - octal-values.forbid-implicit-octal must be true
  - octal-values.forbid-explicit-octal must be true.

Read https://ansible.readthedocs.io/projects/lint/rules/yaml/ for more details regarding why we have these requirements. Fix mode will not be available.
WARNING  Listing 1 violation(s) that are fatal
schema[meta]: $.galaxy_info.platforms[0].versions[0] 18 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/agent_client_collector/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.


Read documentation for instructions on how to ignore specific rule violations.

             Rule Violation Summary              
 count tag          profile rule associated tags 
     1 schema[meta] basic   core 

Issue Type

• Bug Report

OS / ENVIRONMENT

ansible) ➜  ansible-servicenow git:(develop) ✗ ansible-lint --version
ansible-lint 24.9.2 using ansible-core:2.17.5 ansible-compat:24.9.1 ruamel-yaml:0.18.6 ruamel-yaml-clib:None

• ansible installation method: conda
• ansible-lint installation method: conda

STEPS TO REPRODUCE

galaxy_info:
  author: "Dennis Whitney (https://github.com/minsis)"
  description: "My role"
  license: "GPL-3.0-or-later"
  min_ansible_version: "2.15"
  galaxy_tags:
    - "snow"
    - "servicenow"
    - "acc"
  platforms:
    - name: "EL"
      versions:
        - 7
        - 8
    - name: "Ubuntu"
      versions:
        - 18
        - 20
    - name: "opensuse"
      versions:
        - 12
        - 15
    - name: "Amazon Linux 2"
      versions:
        - all
    - name: "Windows"
      versions:
        - 2012
        - 2012r2
        - 2016
        - 2019
    - name: "macOS"
      versions:
        - 10.15
        - Big Sur

Desired Behavior

Validation should be correct despite the order and which OSes are specified.

Possible security bugs should be reported via email to [email protected]

Actual Behavior

Validation is failing by only matching the first item in the schema to the first time in the list.

[Qalthos]

For reference, here is the corrected list (with a few guesses in the case of unclear versions)

  platforms:
    - name: "EL"
      versions:
        - "7"
        - "8"
    - name: "Ubuntu"
      versions:
        - bionic
        - focal
    - name: "opensuse"
      versions:
        - "12.1"
        - "15.2"
    - name: "Amazon Linux"
      versions:
        - all
    - name: "Windows"
      versions:
        - "2012"
        - "2012R2"
        - "2016"
        - "2019"
    - name: "macOS"
      versions:
        - Catalina
        - Big-Sur

Notable surprises:

• Nothing supports numeric values, all numbers must be quoted.
• Ubuntu and macOS only support version names and not numbers.
• "Big-Sur" is not the name of that release.
• Version strings are case-sensitive (2012r2 vs 2012R2).

Things that are probably not issues:

• Integer versions are not a reasonable value for Ubuntu or opensuse, as the major version encompasses both parts of the number
• "Amazon Linux 2", if meant specifically, should be specified with a 2 under the versions key

With that out of the way, the error message is also very bad. It is showing errors from applying the AIX model to anything that fails to validate against any model, likely because they all generate errors and AIX is just the top of the pile. As it exists, the error is almost entirely useless.

Ideally, we should like to only show errors where the name passes validation, and if no such error exists for an entry ("Amazon Linux 2" in this instance), mention that there is no model and list the names from valid models.

[minsis]

I updated to match what you have listed and I no longer get errors.

I'm almost certain that all this was valid a few years back when I first created this collection. Not to say things didn't change but, seems odd that specific options would've been removed that should've been fine.