Azure-pipelines-tasks: Persisting Powershell variables between steps

[MiguelAlho]

Is it possible to define (environment or global) variables in a powershell build step, and be able to use it in another (powershell) step further ahead?

I've been trying to do this, for instance, in a step where a set a variable for the package version by running GitVersion, and then further on, after running the build and tests, tag my repo. The script where I run the tagging step can't get the value of the variable I previously set.

Any recomendations?

Thanks!

[chrispat]

You can use the following command by simply writing it to standard out (Write-Host) in powershell

##vso[task.setvariable variable=testvar;]testvalue

This will make the variable available later in the build and it should be in your environment. We have a behavior change coming in the next deployment (Early September) that will late bind variables references in inputs so you could set a variable in one task and then use it in an input via the $(testvar) syntax and the replacement will happen as expected.

[MiguelAlho]

thanks!

unfortunately, I'm using TFS 2015 and that suggestion doesn't seem to work or i'm completely doing it wrong. As a workaround, I'm persisting the values to file and reading from the file in the steps ahead. I'll change that when late binding becomes available!

[adriaanthomas]

@chrisrpatterson is it possible to give an indication when exactly "Early September" is?

We'd like to use the behaviour change you mention to deploy to a site / slot specifically for a branch. We have a PowerShell script that determines the correct name and calls Write-Host to create a new variable, and would like to use this as input for our deployment task...

[npenin]

@chrisrpatterson Will it happen in TFS on premise ?

[chrispat]

It is in 2015 Update 1

From: Nicolas Penin [mailto:[email protected]]
Sent: Wednesday, October 28, 2015 8:05 AM
To: Microsoft/vso-agent-tasks [email protected]
Cc: Chris Patterson Chris.[email protected]
Subject: Re: [vso-agent-tasks] Persisting Powershell variables between steps (#375)

@chrisrpattersonhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fchrisrpatterson&data=01%7c01%7cChris.Patterson%40microsoft.com%7c3caf80c8a50348d2a1dd08d2df900c93%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TJ4ZLAHjjMfWAmd6wYqbGbRpFuMn3Ebu2mrsO801BJw%3d Will it happen in TFS on premise ?

—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fMicrosoft%2fvso-agent-tasks%2fissues%2f375%23issuecomment-151823523&data=01%7c01%7cChris.Patterson%40microsoft.com%7c3caf80c8a50348d2a1dd08d2df900c93%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ln2lT%2bjlNfLCRJLQzmBqmqvV9O0NLqA53g8wvVWqCAg%3d.

[npenin]

2015 update 1 is available only in english, but our TFS has been installed in French :(

[chrispat]

It is currently only in CTP and we don’t localize those. At RTM you will be able to get it in french.

From: Nicolas Penin [mailto:[email protected]]
Sent: Wednesday, October 28, 2015 9:54 AM
To: Microsoft/vso-agent-tasks [email protected]
Cc: Chris Patterson Chris.[email protected]
Subject: Re: [vso-agent-tasks] Persisting Powershell variables between steps (#375)

2015 update 1 is available only in english, but our TFS has been installed in French :(

—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fMicrosoft%2fvso-agent-tasks%2fissues%2f375%23issuecomment-151851812&data=01%7c01%7cChris.Patterson%40microsoft.com%7cdd60d48ed7264b2f61d908d2df9f3e5f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ela%2b3rl3rAHf8ykTNnK5kSYkK1PdPQLDH8cB7KbmNmk%3d.

[damienpontifex]

This will make the variable available later in the build and it should be in your environment. We have a behavior change coming in the next deployment (Early September) that will late bind variables references in inputs so you could set a variable in one task and then use it in an input via the $(testvar) syntax and the replacement will happen as expected.

@chrisrpatterson has this happened? And is there any documentation on using it?

[chrispat]

https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md you can see the list of commands you can use from scripts. you want task.setvariable

[MiguelAlho]

Can a variable defined in a script (using the technique above) be used in the Repository tab's "Label Format" input?

I've defined a GitVersionTag variable, set in a script using:

Write-Host ##vso[task.setvariable variable=GitVersionTag;]$VersionString

Will the Label Format input late bind to this? My current run tags the repo with the "$(GitVersionTag)" text and not the value.

[MiguelAlho]

Figured it out! By setting build.updatebuildnumber with the logging command:

Write-Host ("##vso[build.updatebuildnumber]$versionToSet")

in the initial script (that's doing a few things other than just getting the version, such as updating assemblyInfo and nuspecs), I can then use $(build.buildNumber) in the Label Format input in the repository tab to tag the repo correctly!

[MylesArkell]

@chrisrpatterson
We have VSO 2015 on prem and just upgraded to update 1, however I have not been able to get this to work. Some people have commented that it was fixed in update 1. Has anyone been able to verify this?

Or am I doing something wrong?

vso[task.setvariable variable=featurePackageName;]$targetNupkg

Write-Host "featurePackageName: "$Env:featurePackageName

the value shows up empty?

[ericsciple]

@MylesArkell In your task/script, you would emit "##vso[task.setvariable variable=featurePackageName;]SomeValue" over STDOUT - if using ps1 script then this could be from unintercepted output or explicit Write-Host calls. If you immediately, check the value of $env:featurePackageName, then the value wouldn't be set. However if you check it in the next task that runs, then the value would be set. Does that help?

[MylesArkell]

@ericsciple thank you very much for your quick reply Eric, I understand now and yes that works perfectly.
I have rewritten it as
Write-Host ("##vso[task.setvariable variable=featurePackageName;]$targetNupkg")

and this is indeed available in future tasks! Fantastic

[tanyabr]

Hi,
I would like to do the same but have the new variable available in other environments. Is this possible? If so - how?

Thanks,
Tanya.

[hcoona]

@chrisrpatterson This tricks only works for one-line varaible. I'd like to load copy file patterns from config file but it contains line-endings as seperator but be consumed in standard copy task in VSO. Is there a more powerful way for it?

[ericsciple]

you can replace carriage return and line feed with the URL encoded equivalents (%0D%0A)

[whihathac]

This will make the variable available later in the build and it should be in your environment.

Does this mean the variable will persist on other agent phases in the same Environment but different Agent Queues?

[iyerusad]

These variables do not appear to persist across phases, only _tasks within the same phase_.

Is there a method to have the variables persist across release phases?

CC: @whihathac @chrisrpatterson et al.

[whihathac]

no clue, I am waiting for an answer too :)

[iyerusad]

@whihathac variables across phases has issue here: https://github.com/Microsoft/vsts-tasks/issues/4743

[sufyannisar]

I am using _PowerShellOnTargetMachines Using File_
I want to change variable value but
Whenever I use Write-Host in Powershell script I get error saying

A command that prompts the user failed because the host program or the command type does not support user interaction. Try a host program that supports user interaction, such as the Windows PowerShell Console or Windows PowerShell ISE, and remove prompt-related commands from command types that do not support user interaction, such as Windows PowerShell workflows.

[ederbond]

Me too @sufyannisar

I am using PowerShellOnTargetMachines Using File
I want to change variable value but
Whenever I use Write-Host in Powershell script I get error saying

A command that prompts the user failed because the host program or the command type does not support user interaction. Try a host program that supports user interaction, such as the Windows PowerShell Console or Windows PowerShell ISE, and remove prompt-related commands from command types that do not support user interaction, such as Windows PowerShell workflows.

[weznagwama]

I'd like to echo Tanya's question: are you able to set/update a variable inside a release, for use in another release?

Or, are you able to update the value of a variable inside of a shared variable group? This could perhaps be in the realm of the API, which I haven't yet looked at...

edit: doesn't look like it.

What i need to do is conditionally deploy a release, as long as another release has been deployed. This is because there's an explicit dependency between the 2 release. In octopus deploy, we have achieved this using variables (true/false or 1/0 if a release/process step is good to go).

[cserkaran]

Is it possible to overwrite System variables e.g. $Env:SYSTEM_DEFAULTWORKINGDIRECTORY in the powershell script using Write-Host

[oleksabor]

I'm trying to set variable in the powerShell task and use in the next one but no luck

````
steps:

• powershell: |
  $fv = Get-Content versionFile
  Write-Host ("##vso[task.setvariable variable=versionFromFile]$fv")
  Write-Host ("fv=$fv versionFromFile=$versionFromFile")
  displayName: 'version from file'

• powershell: |
  if ([string]::IsNullOrEmpty($versionFromFile)) { Throw New-Object System.ArgumentException([string]::Format("failed to read version")) }
  ``` There is exception on the second stepfailed to read version First task output isfv=0.7.3 versionFromFile=` so version was read properly.

Were there any changes in the task.setvariable ? I'm running build on https://dev.azure.com using private agent 2.152.1. Seems that it had been worked before update

[siljemda]

Is there any update on this? I have a global variable named "shouldBuild" with a standard value of "no" and an inline powershell script that uses a switch to check if there are changes. If so it runs the following line:
Write-Host "hello"; Write-Output "##vso[task.setvariable variable=shouldBuild;isOutput=true]ding"

And I can see "hello" being written to the log, but neither immediate write-host of the variable nor later logs in the pipeline display the new value ("ding") - the value is still "no".