"Multi-line [single|double]-quoted string needs to be sufficiently indented" with inline Jinja

[briantist]

Summary

I often split long Jinja expressions over multiple lines, like so:

var: '{{ 
  "123" | int
}}'

But the extension is marking them as an error, with the message shown in the issue title.

Instead it seems it wants me to do something like this:

var: '{{ 
  "123" | int
  }}'

Which imo does not really work visually.

Because the newlines are all within the Jinja templating, there doesn't seem to be any issues with it the way I have it. Since this extension is already aware of Jinja expressions I hope it could detect this case without showing errors in the file.

Extension version

1.0.3

VS Code version

1.57.1

Ansible Version

2.11

OS / Environment

Ubuntu 18.04 (WSL2)

Relevant log output

No response

[tomaciazek]

This is reported by a library which is used for parsing & validating syntax. I'll see what other errors are under YAMLSemanticError category, and maybe this whole category could be reported as warning.

As for disabling it... maybe the extension could expose a setting for it, but it won't be easy to configure - other than the above-mentioned broad category, there's nothing else than the error's description, so that setting would involve some set of pattern-matching strings that the user would need to provide manually.

Anyway, have you considered this:

var: '{{ 
    "123" | int
  }}'

[briantist]

I will look at changing the indent, but it's somewhat a pain to be committing changes to working files to satisfy a parser/validator that in the end isn't following the same rules as the parser used by Ansible, and messing up the git history to do so.

It makes sense to do it if the line would be changed anyway at least, but in the meantime all the other files are highlighted red all over the place (or even yellow if it changes to a warning).

I realize after looking further into it that this is yet another case of different YAML libraries allowing different things, so it's not an easy problem to solve.

A setting that would let us avoid specific errors by (a list of?) [partial] string and/or regex matches would not be the easiest to configure but it would at least be quite flexible, letting anyone cover the things they need.

Thanks again for your time and work on this extension, Tomasz.