find a way to allow use of shellcheck with jinja2 shell script templates (ansible)

[ssbarnea]

More and more shell scripts are migrated from pure bash to being jinja2 templates as they are easily process by ansible.

Sadly at this moment shellcheck cannot be used with shellscripts are jinja templates and it would be really useful to find a way to run it jinja2 templates, even if it may nit cover all jinja2 use-cases.

[ngzhian]

Any way to preprocess your jinja2 templates to feed it to ShellCheck? That way we don't have to add special cases ShellCheck for new file types that are not really shell.

[ssbarnea]

@willthames maybe you have an idea about that? Ability to lint jinja2 templates and what they would produce could be something very handy for ansible.

Clearly we would need a way to process jinja2 during runtime in order to obtain a likely result which should be passed to an external linter. One problem is to identify which linter should be called, as jinja2 can expand to almost anything.

[lonix1]

Did you find a workaround?

These days ansible is used heavily for automation, so scripts contain {{foo}}.

(And this triggers SC1083)

[TomMD]

Saltstack is often paired with Jinja too. It seems we could add a flag --jinja that will allow relaxed syntax parsing, perhaps including a new AST element for conditional portions of scripts (lifting the compile time condition into what is abstractly a run-time condition).

[micheelengronne]

Indeed, my shell scripts include a lot of jinja2 statements ({% %}) for template inheritance. Shellcheck is totally lost with that. I canno't pretemplate them as it breaks the flow of the CI (linters first before doing any transformation to avoid breaking transformations). So, I sadly gave up on shellchecking jinja2 files.

[lonix1]

The fix is to have a disable-then-enable directive as I proposed in #2512.

That is because shellcheck chokes on {{ and }} (and related brace syntax) - but everything else works. So if we could wrap those lines in "disable then enable" directives, everything would work.

(And for any pesky errors/warnings, we could use a normal disable directive, as usual.)