I have an azure devops build pipeline that builds some docker images and a release pipeline that deploys the docker images using some artifacts I publish in the build.

In the build I have some parameters that allow the user to change which docker images are built. Defined like this:

  - name: docker1
    displayName: Build docker image 1?
    type: boolean
    default: true
  - name: docker2
    displayName: Build docker image 2?
    type: boolean
    default: true

I now want to make jobs in my release stages dependent on these variables as well. So something like this: azure devops release interface

Now the config in this picture doesn't work.

My question is how does the syntax for this work if this is just a problem of syntax or how do I make these parameters available to the release if this is more of an issue of variable scope?

What I've tried:

  • Just accessing the parameters with the syntax shown above eq('${{ parameters.docker1 }}', true)
  • Specifying the Build like one would with predefined variables of the build scope eq('${{ Build.parameters.docker1 }}', true)
  • looked at variable groups vaguely based on this post Azure DevOps Build and Release pipeline artifact name variable . Variable groups seem to be immutable from the build pipeline and also shared between multiple potentially simultaneous builds so this doesn't seem to work for this usecase.

I can image that one way to solve this would probably be to write all my parameters to a file, upload this as a pipeline artifact and then write variables from this imported artifact in the release stage. I want to avoid this if possible since it feels like a very clunky workaround.

2 Answers 2


I found another solution that works even without text files just by using the Azure REST API to get the build parameters.

In my release pipeline I execute this Powershell tasks first to extract any build pipeline parameters:

function Get-ObjectMember {
      [Parameter(Mandatory=$True, ValueFromPipeline=$True)]
  $obj | Get-Member -MemberType NoteProperty | ForEach-Object {
      $key = $_.Name
      [PSCustomObject]@{Key = $key; Value = $obj."$key"}

$url = "https://dev.azure.com/$(account)/$(project)/_apis/build/builds/$(Build.BuildId)?api-version=6.0"
$build = Invoke-RestMethod -Uri $url -Headers @{
    Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
$params = $build.templateParameters
if ($params) {
  $params | Get-ObjectMember | foreach {
    Write-Host $_.Key : $_.Value
    echo "##vso[task.setvariable variable=$($_.Key);]$($_.Value)"

My build pipeline contained the parameter: RELEASE_VERSION and after I executed the above code, I can use $(RELEASE_VERSION) in my other release tasks.

  • That actually works perfectly, thanks a lot! Thats way more convenient than what I had before.
    – Dario K.
    Jul 14, 2022 at 11:23
  • Worth mentioning for people with a bit less experience in this, like me, that you need to authorize your release pipeline job to have access to the System Access Token used here. Its under additional options at the bottom.
    – Dario K.
    Jul 14, 2022 at 11:24

In case anyone ever finds this question: I didn't find a satisfying answer. My workaround was to write my variables to a text file in the build and then publish it, download it in the deployment and publish the values as output variables to a bash task. Looks something like this:

source file_containing_your_vars.txt
echo "##vso[task.setvariable variable=var1;isoutput=true]$var1"

the output variables parameters of this bash would need some reference name, for example job_out and you would then be able to reference the variables from other jobs in that stage like this:


If you are running a yaml deployment pipeline (instead of one made in the portal) you can even use job output variable between stages.

For portal pipelines that want to share variables between stages this exists and seems to have helped some people but I didn't get it to work: https://stackoverflow.com/questions/53042605/how-to-modify-azure-devops-release-definition-variable-from-a-release-task/53060141#53060141

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.