ansible - include_tasks: Incorrect type. Expected "object".

[pgassmann]

Visual Studio code incorrectly flags syntax errors with include_tasks and import_tasks

Incorrect type. Expected "object".

related to #96

- import_tasks: foo.yml

- name: manage_bar
  include_tasks: bar.yml

The Schema source extract:
from https://github.com/SchemaStore/schemastore/pull/490/files

          "include_tasks": {
            "type": "object",
            "description": "Includes a file with a list of tasks to be executed in the current playbook.",
            "properties": {
              "free-form": {
                "type": "string",
                "description": "The name of the imported file is specified directly without any other option.\nUnlike M(import_tasks), most keywords, including loops and conditionals, apply to this statement."
              }
            }
          },

[JPinkney]

According to the schema it should be an object whereas the provided snippet it is a scalar. I'm not familiar with ansible so I don't know which is correct but if the snippet is correct there is an error in the schema.

[pgassmann]

The snippet is correct. See documentation: https://docs.ansible.com/ansible/latest/modules/import_tasks_module.html
The documentation also uses free-form or free_form there and in other places to indicate that theres no key: value options, but that the arguments are directly added.
https://docs.ansible.com/ansible/2.3/win_command_module.html

[pgassmann]

By searching the schema for "free-form" I found more modules that lead to this syntax false-error:

- include_vars: bar
- include: bar
- import_playbook: basdf

https://raw.githubusercontent.com/SchemaStore/schemastore/8af13cd3afa7ca67a1c246b38e19602c7e242783/src/schemas/json/ansible-stable-2.5.json

Is this a problem of the schema or of the interpretation of free-form?
What would be the correct schema and how is that schema generated? Where does it need to be fixed?

[JPinkney]

Is this a problem of the schema or of the interpretation of free-form

It looks like its a problem in the schema and also an error in the ansible documentation itself. From what i'm understanding free_form isn't actually a parameter you can specify so the actual type in the schema for include_tasks and import_tasks should be a string. I've filed an issue here and once that fix is applied to the schema on the schema store it should pick up the changes after VSCode is reloaded!

[shaded-enmity]

@JPinkney This is now fixed upstream and new schemas are in SchemaStore.

[JPinkney]

@shaded-enmity Thanks!

[ssbarnea]

I found another case which triggers an invalidation:

- when: true
  block: ...

One workaround is to add a "name:" to these blocks to avoid the very confusing error Missing property "shel" --- when is has nothing to to with shell.

This reminds me of the fact that we probaly need a better way to report a schema error, to send people to the right issue tracker for each schema. Maybe even to advertise this on each popup?

Another issue found was that it complains when it finds an empty setup: section, like:

- setup:
  when: True

The code above is valid YAML as it gives a null dictionary to setup, still, the schema validation fails, forcing user to put something there.

[shaded-enmity]

@ssbarnea Yup, the problem is that LSP (Language server protocol) doesn't really support that in a reasonable manner, I've opened microsoft/language-server-protocol#519 some weeks back.

I think the problem with block is the same thing as using ad-hoc roles inside playbooks etc. can you please help me understand how the block thing is commonly used? I've opened
shaded-enmity/ansible-schema-generator#5 for your last suggestion, and since this is roughly in the same ballpark I'd like to know more so that I can fix it in a general way.

Thanks

[ssbarnea]

@shaded-enmity Check http://codesearch.openstack.org/?q=block%3A&i=nope&files=.yml&repos= for planty of examples of block usage inside playbooks, is very common.

[ssbarnea]

Another problem found:

- set_fact:
    image_cache_path: "{{ _latest }}"
    cacheable: true

The error is that expects string for "cacheable", when we know that bool is clearly acceptable (and likely).

[DanSibbernsen]

FYI: if you're not using a "name" field in any task, the error Missing property "include_vars".yaml-schema: Ansible 2.9 will show up. Adding the "name" field will remove it.