You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
example:
required: truetype: [integer, string]description: "An example parameter"
I don't think st2 can know what to cast the parameter as if I use it in a jinja template.
"{{ example }}" will always be a string, even if I do something like "{{ example | int }}"
In cases where it is not clear what data type something should be, like the above contrived example, If I explicitly run it through a jinja filter that specifies a type, please cast it as that type.
Some parameters can't specify a type because they can have various inputs, but within the context of, say, a particular ansible playbook, I know what type to expect, even if I can't tell ST2 in a schema that this var will be this type. Please allow type casting of jinja templates through either a jinja filter or some kind of new directive.
Finding a way to use the jinja filters will feel cleaner, but I implemented special parsing using directive-like magic strings for INT, AST, and JSON type objects in StackStorm-Exchange/stackstorm-ansible#14. Something more generic would be nice.
edit: see the next comment for publishing variables in action-chain workflows
The text was updated successfully, but these errors were encountered:
cognifloyd
changed the title
for dynamic parameters (multi-type) allow explicit casting of jinja variables
for dynamic parameters (multi-type) or action-chain publishing allow explicit casting of jinja variables
Jun 26, 2017
Here's another time where casting is a problem:
I just tried to publish an object in an action-chain workflow, but then that object is a string and can't be referenced in subesequent jinja templates as some_var.some_attribute. Publish needs the ability to specify what type a published var is.
Usually it's better if a variable / parameter contains only a single type (less ambiguity).
Having said that, there are probably some valid use cases for multiple-types and in that scenario what you have proposed (explicit casting) by the user makes sense.
As far as the implementation goes - would need to dig in, might be a bit complex because of the way and place where the casting is done now.
Usually it's better if a variable / parameter contains only a single type (less ambiguity).
Having said that, there are probably some valid use cases for multiple-types...
True less ambiguity is great when possible. Merely supporting multiple types / dynamic types is probably not as important. Here are my more concrete use cases:
One use case I have is passing stuff into ansible's extra_vars which is a list of either strings or objects. I implemented a workaround for that in StackStorm-Exchange/stackstorm-ansible#14.
The other use case I have is, after running an ansible.command with ansible_module=setup on a single host, I want to publish a facts var in an action-chain workfow:
If I have an workflow parameter like:
I don't think st2 can know what to cast the parameter as if I use it in a jinja template.
"{{ example }}"
will always be a string, even if I do something like"{{ example | int }}"
In cases where it is not clear what data type something should be, like the above contrived example, If I explicitly run it through a jinja filter that specifies a type, please cast it as that type.
Some parameters can't specify a type because they can have various inputs, but within the context of, say, a particular ansible playbook, I know what type to expect, even if I can't tell ST2 in a schema that this var will be this type. Please allow type casting of jinja templates through either a jinja filter or some kind of new directive.
Finding a way to use the jinja filters will feel cleaner, but I implemented special parsing using directive-like magic strings for INT, AST, and JSON type objects in StackStorm-Exchange/stackstorm-ansible#14. Something more generic would be nice.
edit: see the next comment for publishing variables in action-chain workflows
The text was updated successfully, but these errors were encountered: