azure-pipelines-agent: Output variables in downstream job don't exist
Agent Version and Platform
Version of your agent? Hosted VS2017 - Agent version 2.140.0
OS of the machine running the agent? Windows
VSTS Type and Version
VSTS
If VisualStudio.com, what is your account name? https://readify.visualstudio.com
What’s not working?
In the guide Output Variables under Examples it describes using a tasks output variables in a downstream job such as from Job_2 using $(Job_1.TaskA_1.AuthToken). In another task of the same job, this works (without using the Job_1 prefix) but doesn’t in a separate job.
Setup:
- JobA - Hosted VS2017
- PowerShell Task
- inline script
Write-Host "##vso[task.setvariable variable=ChangeFilePath2;isOutput=true]C:\Test" - Output Variables - Reference Name
PS1Output
- inline script
- PowerShell Task
- inline script
Write-Host "This works: $(PS1Output.ChangeFilePath2)"
- inline script
- JobB - Hosted VS2017
- PowerShell Task
- inline script
Write-Host "This doesn't work $(JobA.PS1Output.ChangeFilePath2)"
- inline script
Agent and Worker’s Diagnostic Logs
JobA.PS1Output.ChangeFilePath2 : The term 'JobA.PS1Output.ChangeFilePath2' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 26 (12 by maintainers)
We don’t expect to bring this feature to the designer environments. We’re working on making YAML fully capable to support release pipelines.
Designer pipelines don’t support passing variables from a task in one job to another job. YAML pipelines do support this.
Meaning you have to define the dependency at the job level.
Not sure if it’s the same in yaml when defining variables, but like this from a previous comment when I defined the variable for the entire definition
And thanks for confirming 😄
So TL;DR summary from these discussions:
@vtbassmatt that is a different scenario. The scenario here is consuming the variable in a downstream job (on the agent) - not using the output variable to determine the job condition (orchestrator). Consuming the variable on the agent side requires extra steps to map it into the job message that gets sent down to the agent.