Quoted strings get concatenated when using jinja call block with callback #80605
Comments
|
Files identified in the description: If these files are incorrect, please update the |
|
While debugging this I found the "point of quote removal" is the call to When removing the jinja expression from the playbook, the template uses |
|
The issue with turning A workaround in a template in a play could be: - debug:
var: s1
vars:
s1: "{{ \"'a' 'b'\"|string }}"As for this particular issue, the following diff appears to fix it: diff --git a/lib/ansible/template/__init__.py b/lib/ansible/template/__init__.py
index a623ba52fe9..e3976655491 100644
--- a/lib/ansible/template/__init__.py
+++ b/lib/ansible/template/__init__.py
@@ -593,6 +593,7 @@ class Templar:
# environment there only to override it below
new_env = object.__new__(environment_class)
new_env.__dict__.update(self.environment.__dict__)
+ new_env.concat = environment_class.concat
new_templar = object.__new__(Templar)
new_templar.__dict__.update(self.__dict__)but it needs more testing, I will work on making the diff into a PR. |
|
Thank you very much for the confirmation and the proposed fix. In the hopes of providing a bit of that needed "more testing", I ran it through the following test matrix. The only change in behaviour was that
In the meantime I use the below workaround. The not-trimmed-anymore (indentation-) whitespace at the beginning of the diff --git a/template.j2 b/template.j2
index 07a41a9..14bf684 100644
--- a/template.j2
+++ b/template.j2
@@ -1,9 +1,9 @@
#jinja2: foo:True
{% macro my_macro() %}
- {{ caller() }}
+ {{ caller() |trim }}
{% endmacro %}
-{% call my_macro() -%}
+{% call my_macro() %}
"a" "b"
{% endcall %} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Instead of using Templar.environment in Templar.do_template for accessing/mutating the environment, myenv local variable should be used because it is the environment used for actual templating. It can either point to Templar.environment or newly created environment overlay. Fixes ansible#80605
|
Glad I could be of any help. I tested the PR with both the minimal example above as well as the full setup where I first encountered the issue, both work as expected. So I can confirm the PR fixes my issue. And just for prosperity I ran through the test matrix again. No change in the playbook, but the template now always uses the
Keeping my fingers crossed that the fix will only break a few workflows. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Instead of using Templar.environment in Templar.do_template for accessing/mutating the environment, myenv local variable should be used because it is the environment used for actual templating. It can either point to Templar.environment or newly created environment overlay. Fixes #80605
Instead of using Templar.environment in Templar.do_template for accessing/mutating the environment, myenv local variable should be used because it is the environment used for actual templating. It can either point to Templar.environment or newly created environment overlay. Fixes ansible#80605 (cherry picked from commit 8cd95a8)
Instead of using Templar.environment in Templar.do_template for accessing/mutating the environment, myenv local variable should be used because it is the environment used for actual templating. It can either point to Templar.environment or newly created environment overlay. Fixes ansible#80605 (cherry picked from commit 8cd95a8)
Instead of using Templar.environment in Templar.do_template for accessing/mutating the environment, myenv local variable should be used because it is the environment used for actual templating. It can either point to Templar.environment or newly created environment overlay. Fixes #80605 (cherry picked from commit 8cd95a8)
Instead of using Templar.environment in Templar.do_template for accessing/mutating the environment, myenv local variable should be used because it is the environment used for actual templating. It can either point to Templar.environment or newly created environment overlay. Fixes #80605 (cherry picked from commit 8cd95a8)
Summary
Under certain conditions, using a
templatetask with a jinja call block and a callback that returns a list of quoted strings, the inner quotes are collapsed/removed and the list of quoted strings is turned into a single quoted concatenated string. So instead of"a" "b"the resulting file contains"ab".Issue Type
Bug Report
Component Name
template
Ansible Version
Configuration
OS / Environment
Initially encountered on ArchLinux with the distribution-packages. Later confirmed using the example below on ArchLinux with the version from PyPI and the
develbranch.Steps to Reproduce
ansible.cfg
playbook.yml
template.j2
In a directory with those three files, execute
A few observations I made while reducing the original setup to the minimal example above:
jinja2_native = noinansible.cfg, it works as expected. This is contrary to the template module docs which state "Thejinja2_nativesetting has no effect."templatetask in the playbook does not contain a jinja expression, it works as expected. This is the reason why in the examplesrcis an expression with a constant instead of just a plaintext value.#jinja2line), it works as expected. You get an error if you don't set at least one override, so in the example I set a unusedfoovalue to make it effectively a no-op.-whitespace modifier is removed from the end-delimiter of the call start-statement in the template, it works as expected."a" "b" "c" "d" 'e' 'f' "g" 'h'in the template results in"abcdefgh"in the file. It basically behaves like python's string literal concatenation."a"+ "b"in the template will be written exactly like that into the file.Expected Results
A file
/tmp/outputis created that contains"a" "b"(plus some whitespace around it, but that's not really important here).Actual Results
Code of Conduct
The text was updated successfully, but these errors were encountered: