Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Powershell sub-expression syntax used by TFS/Azure Devops

TFS/Azure DevOps allows you to reference custom variables and built in build/release variables using the following syntax:

$(variable_name)

For example, if I wanted to grab the build definition name, I would grab the value from the following sub-expression:

$(Build.DefinitionName)

But, as far as I can tell, the above syntax is not a valid powershell sub-expression.

If "Build.DefinitionName" was a variable, it would need to look like:

$($Build.DefinitionName)

If it were a collection/hashtable, it would use curly braces:

${Build.DefinitionName}

If it were an object with a static property, it would be:

${Build::DefinitionName}

So what the heck is "Build" in the above example? Is TFS/VSTS/Azure DevOps doing some magic string replacement here or something?

like image 989
RMD Avatar asked Sep 11 '26 19:09

RMD


2 Answers

It's not a Powershell language element, it's a simple TFS/VSTS placeholder syntax, just like SQLCMD uses: https://learn.microsoft.com/en-us/sql/relational-databases/scripting/sqlcmd-use-with-scripting-variables?view=sql-server-2017

TFS/VSTS inserts the values for these placeholders before invoking your Powershell tasks.

like image 103
Leon Bouquiet Avatar answered Sep 14 '26 09:09

Leon Bouquiet


Build/release variables are made available to processes running in the scope of a build/release in the form of environment variables.

As an example, the build definition name is available the same way you'd access any other environment variable in PowerShell: $env:BUILD_DEFINITIONNAME. Note that periods are replaced with underscores.

The exception is secrets. Anything defined as a secret will have to be explicitly passed in to the consuming script, as they are not populated as environment variables.

like image 22
Daniel Mann Avatar answered Sep 14 '26 09:09

Daniel Mann