for dynamic parameters (multi-type) or action-chain publishing allow explicit casting of jinja variables

[cognifloyd]

If I have an workflow parameter like:

example:
  required: true
  type: [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

[cognifloyd]

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.

[Kami]

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.

[cognifloyd]

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:

name: "ansible_setup"
ref: "ansible.command"
  hosts: "all"
  module_name: "setup"
  limit: "{{ ansible_host }}"
  json: True
  inventory_file: "{{ inventory_file }}"
publish:
  facts:  "{{ ansible_setup.stdout[ansible_host].ansible_facts }}"