0
votes

I'm using TFS 2017.1 Builds and Release feature. In my release definition, I have a couple of release variables which I need to refer in my PowerShell task (execute on remote machine). So far, I've tried the following options but couldn't get it to work.

Added an Execute PowerShell task to store release variables into Environment variables:

$releaseVaraiables = Get-ChildItem Env: | Where-Object { $_.Name -like "ACL_*" } 
Write-Host "##vso[task.setvariable variable=aclVariables]$releaseVaraiables"

Added an Execute PowerShell on remote machine task:

Here I can't read the Environment variables (maybe because this is remote machine task?)

Write-Verbose "problem reading $env:aclVariables" -Verbose

Then I tried passing the environment variable as an argument, but that didn't work either

param
(
    $RbacAccessTokenParams
)

$RbacAccessTokenParams.GetEnumerator() | % {$_.Name}
$RbacAccessTokenParams | % {
    Write-Verbose "variable is $_" -Verbose
    Write-Verbose "name is $_.Name" -Verbose
    Write-Verbose "value is $_.Value" -Verbose
}

This is how I passed as argument

-RbacAccessTokenParams $(aclVariables)

What I'm missing here?

2

2 Answers

0
votes

I've tested your scenario on my side with TFS 2017.3.1, and it works when pass the environment variable as an argument. You can upgrade your TFS first and try again. Attach my steps for your reference:

1.enter image description here

2.enter image description here

3.

enter image description here

    4.

enter image description here

0
votes

Non-secret variables are already stored as environment variables; you do not need to do anything special to access them. You can access them with $ENV:VariableName. Periods are replaced with underscores. So Foo.Bar would be $env:FOO_BAR.

Secret variables should be passed in to the script that requires them.

However, this only applies on the agent. If you're using the PowerShell On Target Machines task to run a script, you need to pass the variables as arguments to the script. There is no way around this, unless you choose to use deployment groups.

Or, better yet, follow a configuration-as-code convention and store application-specific values in source controlled configuration files that your scripts read, so that you are not tightly coupled to your deployment orchestration platform.