Azure Pipelines: Passing a variable as a parameter to a template

Question

I am currently evaluating Azure Pipelines with a small POC and I think I have hit a limitation but wanted to know if anyone had a workaround.

Here is the key parts for what I am trying to do.

azure-pipelines.yml

variables:   - name: FavouriteSportsTeam     value: "Houston Rockets" jobs:   - template: Build1.yml     parameters:       SportsTeam: $(FavouriteSportsTeam)   - template: Build2.yml     parameters:       SportsTeam: $(FavouriteSportsTeam) 

Build1.yml

parameters:   SportsTeam: "A Default Team" jobs:   - job: SportsTeamPrinter     steps:       - script: "echo ${{ parameters.SportsTeam }}" 

Now when I attempt to run this, the variable passed from the azure-pipelines.yml file isn't expanded, and it's left as "$(FavouriteSportsTeam)"

Is it possible to pass an expanded variable as a parameter to another file?

Answer 1

I had the same problem with a deployment job within a template where I tried to set the environment depending on a parameter. The template parameter would the receive a run-time variable $(Environment).

The issue was that run-time variables are not yet available at the time the value pass to environment is interpreted. Solution was to not pass the variable in run-time syntax but use the expression syntax ${{ variables.environment }}:

deploy-appservice.yml

parameters: - name: environment # don't pass run-time variables  jobs: - deployment: DeployAppService   environment: ${{ parameters.environment }}   strategy: [...] 

azure-pipelines.yml

- stage: QA   variables:      Environment: QA   jobs:   - template: templates/deploy-appservice.yml     parameters:       environment: ${{ variables.environment }} # use expression syntax 

If you wrongly pass a run-time variable $(Environment) this string is what the deployment job will try to name the Azure DevOps environment. I guess, since this is not a valid name, it will use Test as a fallback name, which then appears in the Environments menu.

---

I have written a more detailed blog post about managing deployment environments on my personal website.