question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Ansible incorrect type errors when using Jinja

See original GitHub issue

I know that the vscode-yaml extension is using schemastore to determine validation syntax but I hoping a solution can occur at this level.

I have been getting really annoying “incorrect type” errors in my Ansible roles when using Jinja placeholders. Here’s an example:

---
# Adds an additional disk to a linux system
# Requires the disk to exist first

- name: Create a filesystem
  filesystem:
    dev: "{{add_disk_device_id}}"
    fstype: "{{add_disk_filesystem}}"
    force: "{{add_disk_force}}"
    opts: "{{add_disk_create_opts}}"
    resizefs: "{{add_disk_resize}}"
  become: yes
  when: linux_add_disk == true


- name: Mount disk
  mount:
    backup: yes
    src: "{{add_disk_device_id}}"
    path: "{{add_disk_mount_path}}"
    fstype: "{{add_disk_filesystem}}"
    opts: "{{add_disk_mount_opts}}"
    state: "{{add_disk_mount_state}}"
  become: yes
  when: linux_add_disk == true

That file throws the following errors: { “resource”: “/Users/shadow/dev/repos/linux-mac-base/ansible/roles/fileshare/tasks/add_disk.yml”, “owner”: “generated_diagnostic_collection_name#0”, “code”: “1”, “severity”: 8, “message”: “Value is not accepted. Valid values: "btrfs", "ext2", "ext3", "ext4", "ext4dev", "f2fs", "lvm", "ocfs2", "reiserfs", "xfs", "vfat", "swap".”, “startLineNumber”: 8, “startColumn”: 13, “endLineNumber”: 8, “endColumn”: 38 } { “resource”: “/Users/shadow/dev/repos/linux-mac-base/ansible/roles/fileshare/tasks/add_disk.yml”, “owner”: “generated_diagnostic_collection_name#0”, “severity”: 8, “message”: “Incorrect type. Expected "boolean".”, “startLineNumber”: 9, “startColumn”: 12, “endLineNumber”: 9, “endColumn”: 32 } { “resource”: “/Users/shadow/dev/repos/linux-mac-base/ansible/roles/fileshare/tasks/add_disk.yml”, “owner”: “generated_diagnostic_collection_name#0”, “severity”: 8, “message”: “Incorrect type. Expected "array".”, “startLineNumber”: 10, “startColumn”: 11, “endLineNumber”: 10, “endColumn”: 37 } { “resource”: “/Users/shadow/dev/repos/linux-mac-base/ansible/roles/fileshare/tasks/add_disk.yml”, “owner”: “generated_diagnostic_collection_name#0”, “severity”: 8, “message”: “Incorrect type. Expected "boolean".”, “startLineNumber”: 11, “startColumn”: 15, “endLineNumber”: 11, “endColumn”: 36 } { “resource”: “/Users/shadow/dev/repos/linux-mac-base/ansible/roles/fileshare/tasks/add_disk.yml”, “owner”: “generated_diagnostic_collection_name#0”, “code”: “1”, “severity”: 8, “message”: “Value is not accepted. Valid values: "absent", "mounted", "present", "unmounted", "remounted".”, “startLineNumber”: 23, “startColumn”: 12, “endLineNumber”: 23, “endColumn”: 38 }


So the easy way to handle this is to ignore an incorrect type error if Jinja syntax is used. Or another possible way is to override specific type errors (but that seems too complicated here, esp. with an autogenerated schema). In all these cases, the Jinja placeholders refer to variables that do contain the correct type or values but the validation occurs without those Jinja expressions being evaluated.

The only way to get around this seems to be disabling YAML validation completely but that seems a bit extreme. Since schemastore is an upstream dependency, I’m hoping a config can be added to vscode-yaml to ignore type errors of the value contains jinja expressions.

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:10
  • Comments:7 (4 by maintainers)

github_iconTop GitHub Comments

3reactions
shadowzen1978commented, May 26, 2020

Unfortunately, I don’t see this as solvable upstream, given that, from the vscode plugin, we have no control over schemastore or the ansible schema generator it uses. Other linters can provide filtering of rules via hooks into a rule “index” but that’s not present in this context.

Maybe a general solution would be an ignore filter that works off of regex that we could use. Then a user could add a list of regex filters based either on the value or the message string.

That gives the user power on how filter regardless of which templating engine is being used. That means I could just add a value match string like \{{2}.*\}{2} to ignore jinja expressions. Or, if ignoring by the message string returned is a better approach, I could filter any messages for ^Incorrect type or ^Value not accepted

Since I’m not clear on how exectly the vscode-yaml plugin integrates with schemastore, if there’s a better way to implement an ignore filter directly within schemastore, let me know and I can make a feature request ticket on that repo instead.

2reactions
JPinkneycommented, May 26, 2020

I actually like the idea of using a regex to specify which values shouldn’t be validated, I didn’t think of that. That way we can technically support all the formats like jinja without having to write in extra code for each specific format.

I’m guessing it would probably be best if a user could set an array of regex’s through a setting rather then one regex because it could be messy if they want to not validate multiple different formats in the same project

Read more comments on GitHub >

github_iconTop Results From Across the Web

Ansible / Jinja2 Unexpected templating type error
But i am getting an "Unexpected templating type error" with the Jinja "sync_do_list() takes 1 positional argument but 2 were given".
Read more >
facts and magic variables — Ansible Documentation
With Ansible you can retrieve or discover certain variables containing information about your remote systems or about Ansible itself.
Read more >
Jinja template variables not working properly
I get the error , it seems Ansible cannot parse beyond {{ hostvars[host]['ansible_facts'] }}. I am using CentOS 7.7.1908 on the control ...
Read more >
Writing jinja as is to file - ansible - Stack Overflow
trying to write dynamically into a consul.tpl file with ansible, the problem is that ansible always tries to parse the Jinja pattern I...
Read more >
Jinja2 filters — Ansible Documentation - Read the Docs
The variable value will be used as is, but the template evaluation will raise an error if it is undefined. Defaulting Undefined Variables¶....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found