Nesting Variables and Value Replacement in Account Defaults & Application Defaults

Hello Everybody.


This article walks you through the details of how you can use a conjunction of Inbuilt Variables with the Account defaults to make resolution dynamic.


You can define Account-wide variables that can be referenced in any entity within a Harness Application. The Account Defaults can include the paths for runtime, staging, and backup used by the scripts in the Service, and can also be used in your Workflow steps or be used as a reference in other Service and Environment Variables.

While these variables are powerful, they are also static and would only resolve to the single value being provided to them. There have been requirements recently from our customers to be able to do value replacement using the Account Defaults as they are globally available. Below is an example of how we can nest Service/Workflow Variables inside the Account defaults or Application defaults to make them dynamic in nature during resolution.

We start by creating and defining Variables for Account level Defaults and then Application Defaults as well :

We will also now need to make these static vars dynamic in nature, and this is achieved by nesting them when suppose there is more than one value to a similar string of variables. To do this, we will be using both a Service level variable and a Workflow level variable, both of which we will be nesting :

Service Level :

Workflow Level :

Once we are all set we can then create a Workflow and add a Shell script step to it and echo the below variables. Here you can see that there are various ways to use these variables and nest them.


echo "${app.defaults['harness_PATH']}"
echo "${app.defaults.harness_PATH}"
echo "${app.defaults[workflow.variables.test + '_PATH']}"
echo "${account.defaults[serviceVariable.testvar + '_HOME']}"

When we execute the Workflow as expected, we can see that the values have resolved to what was defined.

This can be used at scale as well, where you can have multiple defaults on both the Application and Account level, but when these are nested with the Service-specific and Workflow specific variables, they become more dynamic.