0

Before I start using this hack that I found from an article in 2020, I would like to ask if this is a supported feature or is there an easy solution that I have overlooked.

PROBLEM: In a single pipeline, I need to get a variable from a task running on a build machine in one location and pass that over to a task running in a job in another location. Is this even possible? See image below:

Pipeline Variable Definition enter image description here

Pipeline Tasks enter image description here

1 Answer 1

1

No hacks are needed; you can use “Output Variables,” which lets you define variables in one job and then use them in other jobs within the same pipeline.

Here's a quick example:

  1. In the job where you want to create the variable, use this command: ##vso[task.setvariable]. For example:
jobs:
- job: JobA
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: |
      echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]somevalue"

In this case, JobA is creating an output variable called myOutputVar and giving it the value somevalue. 2. Now, in the job where you want to use that variable, you can reference it by using this syntax: $(.).

jobs:
- job: JobB
  dependsOn: JobA
  pool:
  vmImage: 'windows-latest'
  variables:
  myVar: $[ dependencies.JobA.outputs['myOutputVar'] ]
  steps:
  - script: |
    echo $(myVar)

In this example, JobB says, "I need to run after JobA finishes because I want to use that variable it created." It grabs the value of myOutputVar using the syntax  [ dependencies.JobA.outputs['myOutputVar'] ] and assigns it to a variable called myVar. Then, you can use myVar in any of the steps in JobB. Using output variables is a legit non-hack way to pass variables between jobs in different locations within the same pipeline. no hacks required. Just make sure to use the dependsOn keyword to define the order of your jobs, so the variables are ready to go when you need them.

1
  • 1
    Thanks for your answer. I finally came across some something similar to your answer. It appears to be only supported in yaml; which is not the end of the world as devops are actively converting all things to yaml.
    – Ross Bush
    Commented Apr 26 at 12:41

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.