Incorrect type. Expected "string"

[carlbuchmann]

When writing ansible playbook, I get many reported problems where keys contain boolean values or integers... This seems that have started since the last update 4-5 days ago...
example:

Reproduced on both my windows and Linux development workstations with the latest version of vscode: 1.24.1

[gorkem]

Can be related to #93

[cmendible]

Hi guys, same here! It makes my yaml files almost unreadable. Seems to happen with hashes with the latest update.

[JPinkney]

It has nothing to do with the latest update. It has to do ansible files being added to schemastore. This extension pulls from schema store to automatically configure specific well used files. Please file an issue over there and then it will be updated.

[cmendible]

Hmmm that makes sense! I'll check with them...

Thanks!

[cmendible]

I've created the following pull request to fix my issue: SchemaStore/schemastore#480

@carlbuchmann I can confirm that in your case the wrong type is specified in the schemas.

[carlbuchmann]

it looks like the schema files are auto-generated from ansible documentation, so I think it's best to go and fix the source on the ansible repo... it will break again when 2.6 is released!
schemastore: - "Auto-Generated JSON Schema for Ansible-stable 2.5 (https://github.com/shaded-enmity/ansible-schema-generator" -
ansible-schema-generator: generate JSON schema for language servers from Ansible module documentation in an Ansible repository checkout target_path

[cmendible]

Ok so I can confirm that the vscode-yaml plugin has nothing to do with this bug.

We've modified the schemas published in the schema store (SchemaStore/schemastore#480) as quick fix but both ansible documentation (ansible/ansible#42033) and the ansible-schema-generator code (shaded-enmity/ansible-schema-generator#1) must be modified.

[shaded-enmity]

Sorry for the trouble, to avoid further misplacement of issues like this, what do you guys think about adding a top level key to the schema, something like:

"$contact": {
  "name": "John Foo",
  "email": "jfoo@foobar.com"
  "issues": "https://github.com/jfoo/foobar/issues"
}

So that when the schema fails to validate, the extension can peek at the "contact" key and display a personalized message:

Schema failed to validate: ...

If you think this is an error report the issue to the schema author {contact.name} via {contact.issues || contact.email}

[carlbuchmann]

@cmendible did the quick fix work for you?
Since there are 5 schemas published for ansible, which one will be used by this YAML extension... does it detect the ansible version of the local host it is running from or is there a way to manually specify? I'm asking because typically support various major versions currently 2.4.x and 2.5.x

[cmendible]

Hi @carlbuchmann, it did! I don't have ansible installed (I use cloud shell) so it's not detected from local installation... The extension is using the latest ansible schema from: http://json.schemastore.org/ansible-stable-2.5

[shaded-enmity]

@carlbuchmann There's no way to detect Ansible version at the host, as the schema application logic uses simple path matching. The correct way to approach this IMHO would be to allow the user to select which version of schema to use (if there are more) via the UI and defaulting to the latest. Similar to how I can choose Python2 or Python3.

[shaded-enmity]

BTW. I finally realized what is going on in here with the bool/string thing - modules from ansible core are processed first, but those modules contain ill-formed documentation which is disjointed from the non-core modules (note that all docs point to the non-core variants e.g https://docs.ansible.com/ansible/latest/modules/service_module.html).
I've pushed a commit that fixes that and I'll try to regenerate the schemas today in the evening.

[JPinkney]

I'm going to close this because it seems like a schema thing.