Replies: 6 comments
-
It is also not picking up a # noqa jinja[spacing] on the line in question and instead wants it on the header name line. This then disables the checking for ALL the lines in that task which is NOT the desired behavior.
doesn't work, and it should. Instead the only way to suppress the check is for the entire task:
which means that it would potentially miss any jinja[spacing] issues on the other set_fact lines. In this case it was only 3 but it could be 500. Certainly not what was the desired intention. |
Beta Was this translation helpful? Give feedback.
-
I converted this to a discussion because is more of support question than a clean bug report. Please use a YAML loader in order to really see how the comments work or not with multiline blocks. I could help if you could minimize the example as much as possible, to remove anything that is not required for reproducing the issue. That process will likely make you discover that the unexpected behavior is caused by something else. I am not saying that jinja2 spacing rule is free of bugs... ;) just that quite often what appears to be a bug proves to be behavior documented in YAML specification. Try to use https://yaml-multiline.info/ -- Usually is a user fault if you have a quoted string |
Beta Was this translation helpful? Give feedback.
-
So I don't actually understand why this is not a bug.
As you can see this still misses that there is NO SPACE after the '2' based on the {%- control |
Beta Was this translation helpful? Give feedback.
-
Encountering too. I also would consider this a bug. My case is just a vars file with:
This gives:
This makes no sense, because the space is inserted by the |
Beta Was this translation helpful? Give feedback.
-
Seeing the same in a multiline set_fact task and am in favor of this being a bug. |
Beta Was this translation helpful? Give feedback.
-
This is partially a limitation in YAML of course with there not being a way to have multiple lines that are simply joined without adding whitespaces, at least not something that isn't ugly in another way, although the {%- in Jinja should take care of any unintended spaces. if you have something like:
The "\n" after the values will be converted to a whitespace by YAML. The only way to fix it to me seems to make the code less readable and more clunky, e.g.:
While this prevents unintended whitespaces it looks a lot worse than having the Jinja2 control structures on their own lines. This is a different way to do this without tripping up ansible-lint but it requires using more python syntax instead of jinja.
I really don't think the linter should flag a space between -%} {%- as an issue. |
Beta Was this translation helpful? Give feedback.
-
Summary
When you have a long jinja2 statement that you need to break up over multiple lines, it is not reading the whitespace control directives
Issue Type
OS / ENVIRONMENT
STEPS TO REPRODUCE
Desired Behavior
ansible-lint correctly interprets the {%- directive which removes the after _vhs
Actual Behavior
Beta Was this translation helpful? Give feedback.
All reactions