A customer question came up in my current role on how they can use the output of an Azure DevOps Pipeline’s stage in another stage. This reminds me of a similar problem I ran into in the past, where a variable’s value is set in one of the pipeline’s job, but once the job is finished, its value is lost (i.e. the next job doesn’t have that updated value).
This problem is caused by the fact that the command ‘task.setvariable‘ is scoped at the agent level. If you read the documentation carefully, it says “[…] it does make the new variable available to downstream steps within the same job.” Well, that clearly confirms that the next job won’t be able to see that updated value. Each pipeline job can be executed by a different agent, so the next agent has no idea about the values of the previous agent. Sigh.
Some quick Googling sent me to Chaminda’s blog post (thanks so much Chaminda!). I was able to successfully implement this approach with some slight variations in my pipeline (since I can’t seem to get the marketplace Run PowerShell extension he mentioned to work – I think it’s a problem with Azure DevOps at the exact time of this writing).
Here’s what I set up for my release pipeline for demonstration purposes:
A variable named “RequestNumber” with a static value of “0000” (This is so I know what value I’m getting back when I debug this pipeline). This variable is scoped at the Release level.
My release pipeline has 2 Stages – one to set the variable, and one to consume it.
- “Set Variable” Stage – Job #1 (make sure both of the following tasks belong in the same job):
- Make sure to check the “Allow scripts to access the OAuth token” option for the job.
- Task #1: Call a mock REST API to simulate adding a new record of some sort (let’s say a new ServiceNow Change Request). The output of this task’s API call is the ID of my newly created request. I also use the “task.setvariable” command in this task to update my “RequestNumber” variable’s value. And we know this works, but its value will not persist in the next job (as explained previously). This is why we’ll add the following Task #2.
- Task #2: This task uses the Powershell script mentioned from the aforementioned blog post to update the RequestNumber variable once more, but this time it’s updated at the Release level.
2. “Consume Variable” Stage – Job #1:
- Task #1: My task is simply displaying the “RequestNumber” variable to confirm that it indeed has the new value, and not “0000”. In your situation, you’ll end up doing other more complicated actions using this variable.
For testing purposes, if I disable Task #2 in the “Set Variable” Stage, the “Consume Variable” Stage ends up with the static value of “0000,” even though Task #1 of the “Set Variable” stage updated it to be something else.
Also, even though I didn’t have it listed in this blog post, if you add a second job in the same first stage to write out the value of this variable, you’ll see that the variable has the correct updated value as well.
You can see my exported pipeline and the PowerShell script files HERE.
If time allows, I’ll try to turn this into a Marketplace extension. Happy deploying!
