PowerShell task

Azure Pipelines | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015

Use this task in a build or release pipeline to run a PowerShell script.

Note

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

Demands

  • DotNetFramework

YAML snippet

# PowerShell
# Run a PowerShell script on Windows, macOS, or Linux.
- task: PowerShell@2
  inputs:
    #targetType: # 'filePath' or 'inline'; defaults to filePath
    #filePath: # required when targetType == FilePath
    #arguments: # optional arguments passed to PowerShell
    #script: # required when targetType == Inline; actual contents of the script
    #errorActionPreference: # options: stop, continue, silentlyContinue; defaults to 'stop'
    #failOnStderr: # optional, defaults to false
    #ignoreLASTEXITCODE: # optional, defaults to false
    #pwsh: # optional, always use PowerShell Core (even on Windows); defaults to false
    #workingDirectory: # optional, initial working directory

The Powershell task also has a shortcut syntax in YAML:

- powershell:  # inline script
  workingDirectory:  #
  displayName:  #
  failOnStderr:  #
  errorActionPreference:  #
  ignoreLASTEXITCODE:  #
  env:  # mapping of environment variables to add

Arguments

ArgumentDescription
TypeSets whether this is an inline script or a path to a .ps1 file. Defaults to filepath
File pathPath of the script to execute. Must be a fully qualified path or relative to $(System.DefaultWorkingDirectory). Required if Type is filePath.
ArgumentsArguments passed to the Powershell script. Ignored when Type is inline.
ScriptContents of the script. Required if Type is inline.
Working directorySpecify the working directory in which you want to run the command. If you leave it empty, the working directory is $(Build.SourcesDirectory).
Fail on standard error If this is true, this task will fail if any errors are written to stderr.
errorActionPreference Set PowerShell's error action preference. One of: stop, continue, silentlyContinue. Defaults to stop.
ignoreLASTEXITCODE By default, the last exit code returned from your script will be checked and, if non-zero, treated as a step failure. If you don't want this behavior, set this to true.
Environment variables A list of additional 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)

Control options

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 a warning 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

Open source

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

Q & A

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?

Define and modify your build variables in a script

Define and modify your release variables in a script

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

A: Try this:

  1. On the variables tab, add system.debug and set it to true. Select to allow at queue time.

  2. In the explorer tab, view your completed build and click the build step to view its output.

The control options arguments described above can also be useful when you're trying to isolate a problem.

Q: How do variables work? What variables are available for me to use in the arguments?

A: $(Build.SourcesDirectory) and $(Agent.BuildDirectory) are just a few of the variables you can use. See Variables.

Do I need an agent?

You need at least one agent to run your build or release. Get an agent for Linux, macOS, or Windows.

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.

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.