Stand Alone Task File linting skipped as generic yaml file

[MrBones757]

Summary

When linting a task file, ansible-lint detects the file type as a generic yaml file and doesn't perform ansible specific
Related Issue: #280

Issue Type

• Bug Report

OS / ENVIRONMENT

ansible-lint 6.16.0 using ansible 2.14.5

• ansible installation method: pip
• ansible-lint installation method: pip

STEPS TO REPRODUCE

ansible-lint --project-dir ./ task-file.yml -vv

Desired Behavior

ansible lint should perform task file linting on the file

Actual Behavior

Ansible lint detects the file a generic yaml and does not apply ansible lint logic, only standard yaml
Debug Line below:

Passed 'post_tasks.yml' positional argument was identified as generic 'yaml' file kind.

[MrBones757]

I would be willing to provide a PR to add this functionality.
We have experimented internally, and one way we came up with was to annotate the file with the desired kind.
This would be similar to how the yaml language server for vscode handles schemas, but more ansible-lint specific:
redhat-developer/vscode-yaml#401

The General idea would be to add a line such as the one below to the first line of a file, and allow ansible-lint to look at this for a kind hint.

# ansiblelint kind=tasks

When loading the file, some logic like the section below could be used to check the first line's content without affecting the standard yaml load should that line not exist. (Note this is an example for demonstration only)

import yaml

def get_line(f):
    pos = f.tell()
    line = f.readline()
    f.seek(pos)
    return line

with open("test.yml", "r") as stream:
    first_line = get_line(stream).strip("# ")
    if first_line.startswith("ansiblelint"):
      ansiblelint_params=first_line.replace("ansiblelint","").strip()
      params = {k: v for k, v in (item.split('=') for item in ansiblelint_params.split())}
      print(params)
    try:
        data = yaml.safe_load(stream)
    except yaml.YAMLError as exc:
        print(exc)

A simple yaml file can be used to test this code locally to validate.

[ssbarnea]

You missed to include the most important part, the content of the file! Without it, a random YAML file passed to the linter would be identified as just YAML and not something else.

Regarding adding a magic comment, don't work on it yet, let us think a little bit before doing the work as we need to agree on the format to be used.

For example https://developers.redhat.com/blog/2020/11/25/how-to-configure-yaml-schema-to-make-editing-files-easier#schema_registry mentions a syntax that is specific to yaml-language-server, and that would be extra long and hard to type, also unite to a specific implementation.

# yaml-language-server: $schema=https://my.url.to/the/schema

I will talk with the team behind yaml-language-server project to see if we can come up with a short way to describe the schema of the document, so we can implement support for it in all projects that might make use of it, 3 i know so far:

• ansible-lint
• vscode-ansible extension (and associated yaml-language-server)
• vscode-yaml extension (and associated ansible-language-server)

Still, we still need SchemaStore/schemastore#2954 or similar in order to implement something like this.

[MrBones757]

Thanks for your reply on this one.

We hadn't put much effort into this, other than to look though the code and figure out how the files were being read / processed, and how, currently, the files were being classified as playbook or rulebook.

We did note that schemas are built into ansible-lint for things like tasks and playbooks, as such, we thought about using those to verify the user's defined type and return errors if the schema validations returned errors as a kind of verification for the manual classification.

We used the method provided by the yaml language server as an example / basis to base these thaughts on, and in a similar way to how that tool deals with schema validation, we kind of figured that in such a case where the user is able to define the file schema explicitly, it would be up to the user to make sure it aligns correctly to the file type, and any checks against a schema matching the user's definition would result in lint errors and give an indication of correctness for the assigned type. In addition to this, it would be make sense that any type not in a "known lookup list", "permitted schema list for the current lint tool", like the central schema repository you have referenced, would return either an invalid schema reference error, or correct-schema-wrong-linter kind of error.

Just kind of thinking out loud on the points above, in the hopes of contributing or helping result in a positive outcome and feature expansion for the tool.
Internally at my workplace, the linter has been a great help across our teams to give early warnings for incorrect file syntax, and to aid in our upgrade processes. It would be nice if we were able to give back to the community by helping add features to the tooling we use, and, with the addition of a feature like this, we could better inform our internal teams and others more broadly in additional areas of the ansible ecosystem :)