Azure-devops-docs: Nested variables don't work

[zarochi]

This article should note that by design nested variables don't work. IE, a variable where part of its name is derived from another variable. For instance $(sql-password-$(Build.SourceBranchName)) evaluates as $(sql-password-branchname) instead of the SQL password value you had set to the variable earlier. It took a while to find this out, and it would have saved me a few hours if it had been on here.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: dd7e0bd3-1f7d-d7b6-cc72-5ef63c31b46a
• Version Independent ID: dae87abd-b73d-9120-bcdb-6097d4b40f2a
• Content: Variables - Azure Pipelines
• Content Source: docs/pipelines/process/variables.md
• Product: devops
• Technology: devops-cicd
• GitHub Login: @steved0x
• Microsoft Alias: sdanie

[paule96]

I have the same problem but a little bit different. The key vault integration in Azure DevOps required the described behavior to work dynamically.

Because if I have a variable that describes the name of the secret, like this:

$(secretName) == "mySuperSecretName"

The key vault task creates a new secret variable with the name mySuperSecretName. So I would access the content of this with the following expression:

$($secretName)) == "mySecretValue"

But this doesn't work as described above.

[paule96]

Maybe this is a bug for the variable syntax team at Microsoft. Because that would be nice if this would work.

[zarochi]

I'm a little confused by what you're saying/asking, but I'll give it my best shot. All variables are referenced as $(secretName) in pipeline YAML, so I have no idea what you're even trying to do with $($secretName)) (You also have an extra parenthesis in there).

It's by design unfortunately that nested variables don't work. I found a workaround for my situation that involves using a powershell task. If you do something like this in a powershell task it should do what you're looking for:
write-host "##vso[task.setvariable variable=NewSecretName]$(OldSecretName)"

This allows you to access $(NewSecretName) as a variable with the same value as $(OldSecretName)

[paule96]

yes, this is a workaround but not a very good one if you have many builds or pipelines.

yes you are right. I missed a parenthesis. $($(secretName)) == "mySecretValue".

What I'm saying are these steps:

# original expression
$($(secretName))
# interpretation
$(mySuperSecretName)

That should be the goal. I need the mySuperSecretName as value, so the key vault task know what secret it must resolves and has the name also as secret key, because the key vault task will create a new variable with the name of the secret. (that means a new variable with the name mySuperSecretName is created)

[zarochi]

Sounds like you went through the same process I did with this whole thing. I ended up using the same powershell snippet in like 10 different pipelines to get around it for now. Hopefully this gets enough priority to become a feature.

My biggest ask for MS on this one is to simply update the documentation in the mean time to indicate this doesn't work, so others don't waste their time on it and go straight to the workarounds we're aware of now.

For any lurkers, see this stack posting for the same issue: https://stackoverflow.com/questions/46736978/vsts-nested-variables

[juliakm]

Thanks for flagging this. I'm working to get more information from the product team on what should be possible with nested variables.

[JoeBrockhaus]

I have seen this sometimes work and sometimes not work.

My best guess has been _order_ in the physical yaml vs when parsed is not guaranteed to be the same _(alphabetical?)_. It would be nice if, at least in the case of _dependency resolution_, that ordering were performed topologically.

I had a multi-variable compound variable, and each time the same variable would fail to replace. Like you, after spending _way too much time_, I simply reverted to an annoying script task. _(You could leverage templates to obscure this by incurring some syntax wonkiness by injecting jobs/steps as template params..)_

[juliakm]

To follow-up, the product team is working on clarifying how nested variables should work. I will update the documentation when we have more information.

[juliakm]

Thanks for your patience on this. I checked with the product team and there are places where variables will expand when nested, and the behavior will be slightly different if you specify variables with macro syntax (example: $(var)). However, this is not an officially supported feature and their recommendation is to not document macro variables as expanding recursively.

If you would like to reach out the product team directly, please post in the Azure DevOps Developer Community. The product team actively monitors that space.