Currently variables in the context section of the recipe cannot be lists. If a Jinja filter produces a list (e.g. the string split filter) and that value is stored to a variable, it ends up being stringified. This leads to surprising errors downstream, such as if you attempt to index into the result or collapse it back into a scalar object (e.g. via the join filter on a split string) and it is treated as a string. Ideally the context would support list variables, but it should at least provide better error messages for debugging by not silently converting the list to a string but instead failing to assign it. The current behavior can lead to very unexpected errors. For instance, continuing the example from above, if we do something like this
context:
x: "one.two.three"
y: ${{ x | split(".") }}
z: ${{ y | join(".") }}
The value of z will not be one.two.three but instead [.".o.n.e.".,. .".t.w.o.".,. .".t.h.r.e.e.".] since y is the string ["one", "two", "three"], not a list of three elements.
Currently variables in the
contextsection of the recipe cannot be lists. If a Jinja filter produces a list (e.g. the stringsplitfilter) and that value is stored to a variable, it ends up being stringified. This leads to surprising errors downstream, such as if you attempt to index into the result or collapse it back into a scalar object (e.g. via thejoinfilter on asplitstring) and it is treated as a string. Ideally the context would support list variables, but it should at least provide better error messages for debugging by not silently converting the list to a string but instead failing to assign it. The current behavior can lead to very unexpected errors. For instance, continuing the example from above, if we do something like thisThe value of
zwill not beone.two.threebut instead[.".o.n.e.".,. .".t.w.o.".,. .".t.h.r.e.e.".]since y is the string["one", "two", "three"], not a list of three elements.