The Load Variable action can be used to load the current value of Configuration, Project and Application variables into a build variable. These are the variables that you can edit manually on the server and are referred to as Server variables. Loading the value into a build variable allow it to be accessible during the build using the expression %VariableName%.
A friendly name for this action (will be displayed in the actions workflow area).
Determines if this action will be run within the relevant stage.
This drop down contains a list of Configuration, Project and Application variables accessible to the configuration. See Variables for details on how to create a variable. Note that Expression variables cannot be modified and are therefore not listed.
If this option is ticked, then the server variable value will be expanded, (if there's any expressions in it), before it is loaded into the build variable
Tick this to leave the value of agent variables as they are. Agent variables are accessed using variable expressions prefixed with a namespace, such as %Configuration.VariableName%, %Project.VariableName% and %Application.VariableName% and typically contain the value of the server variable at the start of the build. By default, without this option ticked the corresponding agent variable will be updated with the value of server variable.
Tick this option to acquire a the write lock on the server variable until the end of the build. This will prevent other builds and users from updating the variable value for the duration of the build.
Tick this option to release the write lock at the end of the stage rather than the end of the build.
If a write lock is required and the server variable is locked by another build, the build will wait until the server variable lock is released and is available for writing. The maximum time it will wait can be set here. By default, it will wait for 24 hours,.
If a write lock is required and the server variable is locked by another build, the current build will, by default, wait 3 seconds before retrying. This delay between retries can be set here. If this the value is set to zero then the default of 3 seconds will be used. Shorter delays may have a performance impact on server. Longer delays will mean that the build takes longer to to respond to the lock being released.
Note that there is no queueing - if more than one build is waiting for a variable lock, then the order in which the lock is acquired depends on which build makes a lock request first after the lock is released. So the order is essentially arbitrary.
Tick to display more verbose information in the build log