0
votes

I am reading this article: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=classic%2Cbatch#set-in-script

The Powershell script example shown here: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=classic%2Cpowershell#set-a-job-scoped-variable-from-a-script-1

I assume that "Set the sauce and secret.Sauce variables" is one task and "Read the variables" is another task. And that the arguments are passed as task arguments.

If so (that is - value set in one powershell task can be utilized in another powershell task), then, why does the section below this (see https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=classic%2Cpowershell#using-variables-as-task-inputs) advise that:

In order to use a variable as a task input, the variable must be an output variable and you must give the producing task a reference name.

This section (https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#set-a-multi-job-output-variable) says:

If you want to make a variable available to future jobs, you must mark it as an output variable using isOutput=true.

1
Just want to check whether the below explanation is help for you? Did you still has any puzzle about the output variable? If not help, feel free to leave comment below.Merlin Liang - MSFT

1 Answers

2
votes

First, what you assumed about

"Set the sauce and secret.Sauce variables" is one task and "Read the variables" is another task

is correct. If you read it in the same task, you would receive the error like "{output variable name}" could be recognized.

If using variable in the same job, use $() directly is same with using $(<ReferenceName>.<VariableName>) in most of scenarios, including getting variables in one agent job and did not set the variables with the same name in another task. But, obviously, $() is a most easier method.


  • 1. If you set the variable with the same name in another task.

    Sometimes, you may need execute the same script with different condition, so its result may have same name but value different. In one word, you need set different values in different tasks by using the same variable name. And then you need perform the next task according to the values which generated in different states.

    At this time, using $(<ReferenceName>.<output VariableName>) is a better solution, to get the specific variable value that set in which state. Because the read action can only get the the latest value assignment.

  • 2. If you want to use this variable in different agent job

    In some large projects, the next agent job needs to use the variables which set in last agent job(Note: These 2 jobs must in the same pipeline). Re-running the script to set the variable will increase the time spent of the build, which will also increase the cost of the code verification.

    With this condition, $(<ReferenceName>.<output VariableName>) is the only approach that can achieve this scenario.

    BUT, until now, this approach only support YAML schema. If you use classic editor to achieve this scenario, you can only re-write the set variable script.