Variables

Actions might provide users a way to access and reuse their results. For example, the "Run script" action provides the user a way of knowing the exact exit code of the script and the STDOUT content, among other data. This information can be accessed via variables.

Each action's settings will use a green banner at the bottom of the popup in order to let you know if it provides a variable, and if it does, it will let you set a custom name for it.

User defined variables

Having the results of actions stored in variables is an useful feature that helps design complex blueprints. But there are situations in which the user might want to define it's own variables and assign them custom values (for example, a variable that contains the IP address of a target machine). This is why a special action called "Define variables" exists.

Using variables

Let's dig a little bit deeper into what variables are exactly and how to use them! A variable is a, so to say, pointer to a chunk of information. That information can be a primitive value such as an integer or a string, or it might be a complex hashmap with nested levels of attributes.

For example, when we defined the foo and bar variables in the previous video, we were actually defining 2 strings. The values of these strings combined together would read as "hello world!". We can reference these values by using interpolation with double curly braces ({{ }}).

Let's say that we want to print the values of these two variables to STDOUT. We can use the "Log" action and fill it's "Content" field with {{ foo }} {{ bar }}. Once the CLI starts executing the blueprint, it will be able to evaluate and interpolate these values at runtime and use their values.

Accessing nested levels of attributes of a variable is performed using JSONPath notation. Examples:

{{ RunScript_Result.exit_code }} - Retrieves a property called exit_code from the variable RunScript_Result

{{ AWS_EC2.networkInterfaceSet[0] }} - Retrieves the first network interface of the list of network interfaces attached to the AWS EC2 instance that is stored in the variable called AWS_EC2

Trying to print a variable that is not a primitive value will print a JSON representation of the structure of the variable, giving you the possibility to inspect all of it's attributes and values.

Variable interpolation works in any editable field in the settings of all actions. Furthermore, many fields have advanced autocomplete features, which means that you'll be presented with a list of variables that match the type of data that the field you're filling expects.

Keep in mind that you can only use variables, in the settings of an action, that were created by previous actions, because these actions were created by the execution flow. You can't use variables exposed by actions that haven't been reached yet by the execution flow, because these variables haven't been created yet.

Last, but not least important, all available variables will appear in the sidebar on the right. Variables exposed by actions that are not part of the evaluable blueprint won't be shown.

Additional tips & tricks

All variables have a few "magic" properties. You might find them useful:

• __id - Returns the ID of the resource that is stored in the variable. Note that not all variables hold a resource, which means that not all variables have an id property. For example, a variable produced by the RunScript action won't have an id property, while a variable produced by the Find EC2 instance will, because that variable holds a cloud resource which contains an ID of some sort.
• __hasError - A boolean flag indicating whether the action that produced the variable failed at executing the task it was supposed to execute.
• __error - A string containing the error (if any) reported by the action that produced the variable.

If you made it so far, congratulations! You should be able to start exploring Nebulant and create your own basic blueprints. There are some advanced topics that we'll cover in the following chapters. Proceed whenever you're ready!