PowerShell task

發行項
08/25/2020

TFS 2017 | TFS 2015

Use this task to run a PowerShell script.

Note

In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.

Demands

DotNetFramework

Arguments

Argument	Description
`targetType` Type	(Optional) Sets whether this value is an inline script or a path to a `.ps1` file. Defaults to `filepath` Default value: filePath
`filePath` Script Path	(Required) Path of the script to execute. Must be a fully qualified path or relative to `$(System.DefaultWorkingDirectory)`. Required if Type is `filePath`
`arguments` Arguments	(Optional) Arguments passed to the PowerShell script. For example, `-Name someName -Path -Value "Some long string value"` Note: unused when Type is `inline`.
`script` Script	(Required) Contents of the script. Required if targetType is `inline`. The maximum supported inline script length is 32766 characters. If you need more than that limit allows, use the script from file. Default value: # Write your PowerShell commands here. Write-Host "Hello World"
`errorActionPreference` ErrorActionPreference	(Optional) When not "default", prepends the line `$ErrorActionPreference = 'VALUE'` at the top of your script Default value: stop
`warningPreference` WarningPreference	(Optional) When not "default", prepends the line `$WarningPreference = 'VALUE'` at the top of your script Default value: default
`informationPreference` InformationPreference	(Optional) When not "default", prepends the line `$InformationPreference = 'VALUE'` at the top of your script Default value: default
`verbosePreference` VerbosePreference	(Optional) When not "default", prepends the line `$VerbosePreference = 'VALUE'` at the top of your script Default value: default
`debugPreference` DebugPreference	(Optional) When not "default", prepends the line `$DebugPreference = 'VALUE'` at the top of your script Default value: default
`failOnStderr` Fail on Standard Error	(Optional) If this value is true, this task will fail if any errors are written to the error pipeline, or if any data is written to the Standard Error stream. Otherwise the task will rely on the exit code to determine failure Default value: false
`ignoreLASTEXITCODE` Ignore $LASTEXITCODE	(Optional) If this is false, the line `if ((Test-Path -LiteralPath variable:\\LASTEXITCODE)) { exit $LASTEXITCODE }` is appended to the end of your script. This change will cause the last exit code from an external command to be propagated as the exit code of PowerShell. Otherwise the line is not appended to the end of your script Default value: false
`pwsh` Use PowerShell Core	(Optional) If this value is true, then on Windows the task will use pwsh.exe from your PATH instead of powershell.exe Default value: false
`workingDirectory` Working directory	(Optional) Specify the working directory in which you want to run the command. If you leave it empty, the working directory is `$(Build.SourcesDirectory)`
Environment variables	A list of other items to map into the process's environment. For example, secret variables are not automatically mapped. If you have a secret variable called `Foo`, you can map it in like this: `- powershell: echo $env:MYSECRET env: MySecret: $(Foo)`

Examples

Hello World

Create test.ps1 at the root of your repo:

Write-Host "Hello World from $Env:AGENT_NAME."
Write-Host "My ID is $Env:AGENT_ID."
Write-Host "AGENT_WORKFOLDER contents:"
gci $Env:AGENT_WORKFOLDER
Write-Host "AGENT_BUILDDIRECTORY contents:"
gci $Env:AGENT_BUILDDIRECTORY
Write-Host "BUILD_SOURCESDIRECTORY contents:"
gci $Env:BUILD_SOURCESDIRECTORY
Write-Host "Over and out."

On the Build tab of a build pipeline, add this task:

Task	Arguments
Utility: PowerShell	Run test.ps1. Script filename: `test.ps1`

Write a warning

Add the PowerShell task, set the Type to inline, and paste in this script:

# Writes a warning to build summary and to log in yellow text
Write-Host  "##vso[task.LogIssue type=warning;]This is the warning"

Write an error

Add the PowerShell task, set the Type to inline, and paste in this script:

# Writes an error to build summary and to log in red text
Write-Host  "##vso[task.LogIssue type=error;]This is the error"

Tip

If you want this error to fail the build, then add this line:

exit 1

ApplyVersionToAssemblies.ps1

Use a script to customize your build pipeline

Call PowerShell script with multiple arguments

Create PowerShell script test2.ps1:

param ($input1, $input2)
Write-Host "$input1 $input2"

In your YAML pipeline, call:

- task: PowerShell@2
  inputs:
    targetType: 'filePath'
    filePath: $(System.DefaultWorkingDirectory)\test2.ps1
    arguments: > # Use this to avoid newline characters in multiline string
      -input1 "Hello"
      -input2 "World"
  displayName: 'Print Hello World'

Open source

This task is open source on GitHub. Feedback and contributions are welcome.

FAQ

Where can I learn about PowerShell scripts?

Scripting with Windows PowerShell

Microsoft Script Center (the Scripting Guys)

Windows PowerShell Tutorial

PowerShell.org

How do I set a variable so that it can be read by subsequent scripts and tasks?

To learn more about defining build variables in a script, see Define and modify your build variables in a script.

To learn more about defining release variables in a script, see Define and modify your release variables in a script

Q: I'm having issues with publishing my artifacts. How can I view the detailed logs?

To enable detailed logs for your pipeline:

Edit your pipeline and select Variables
Add a new variable with the name System.Debug and value true
Save

Q: Which variables are available to me?

A: $(Build.SourcesDirectory) and $(Agent.BuildDirectory) are just few of the variables you can use in your pipeline. Variables are available as expressions or scripts.

See Define variables, predefined variables, and Classic release and artifacts variables to learn about the different types of variables.

Q: Task allows me to publish artifacts in deployment job in yaml pipeline, but I am not able to use it in downstream pipeline?

A: Deployment jobs do not have the context of source branches and are hence not appropriate for publishing artifacts. They have been primarily designed to consume artifacts. A workaround would be to isolate that logic into a separate job (with dependencies on your deployment jobs).

Do I need an agent?

You need at least one agent to run your build or release.

I'm having problems. How can I troubleshoot them?

See Troubleshoot Build and Release.

I can't select a default agent pool and I can't queue my build or release. How do I fix this?

See Agent pools.

My NuGet push task is failing with the following error: "Error: unable to get local issuer certificate". How can I fix this?

This can be fixed by adding a trusted root certificate. You can either add the NODE_EXTRA_CA_CERTS=file environment variable to your build agent, or you can add the NODE.EXTRA.CA.CERTS=file task variable in your pipeline. See Node.js documentation for more details about this variable. See Set variables in a pipeline for instructions on setting a variable in your pipeline.

I use TFS on-premises and I don't see some of these features. Why not?

Some of these features are available only on Azure Pipelines and not yet available on-premises. Some features are available on-premises if you have upgraded to the latest version of TFS.

I'm using PowerShell task and passing secret in script, but secret is not masked in pipeline logs

Be aware that PowerShell cuts off error message, so if you use some secrets in the script - they could be trimmed as well, and won't be masked in this case. For example, for the inline script below:

./script.ps1 --arg1 value1 --arg2 <some_secret_which_will_be_masked_here>

There could be an exception like: At <path_to_temp_script_file>:4 char:3

+   ./script.ps1 --arg1 value1 --arg2 <unmasked_part_of_original_secret> ...
+   ~~~~~~~~~~
    + <Additional exception details>

To avoid this issue you can handle such exceptions on a script level, or avoid cases when secrets could appear in the source code line in the error message.