Converting PowerShell Tasks in YAML

YAML builds have many advantages over traditional build definitions, especially because YAML build definitions follows branching of code, a killer feature that is fantastic if you use GitFlow.

YAML build definitions are stored in code, this allows them to follow branches, minimizing the need to maintain builds that should build code in a different moment in time.

As an example, I have a build where I have tasks to publish some web sites. If I had a new web site to publish, I could add another task in the YAML build, but the build still works for older branches, especially for the master branch that represents my code in production.

To minimize the impact, I tend to use PowerShell scripts stored inside the code repository to perform build tasks. This was an old trick useful when YAML build was not present. Scripts allows you to create a generic build, add some tasks to run PowerShell scripts, and the result is that scripts follow branches.

Now that a YAML build is available, I started converting everything to a YAML build, a task that is made simple thanks to a nice feature of VSTS; in the UI, there is a nice "View YAML" button that converts all of my build definitions to new YAML syntax.

Figure 1: The UI functionality shows the current standard build definition translated to a new YAML build definition.

As you can see from Figure 1, PowerShell tasks are not converted as a task, but with a node of type PowerShell, followed by parameters. This is perfectly valid because a YAML build can contain a PowerShell node, but in my specific situation, the build failed because the conversion failed to set up a working directory.

Even if a YAML build allows a direct call of PowerShell scripts, if you convert a working build that uses a PowerShell task, it is better to use the same task inside the YAML definition.

To solve my problem, I simply changed the generated YAML build definition to use a standard PowerShell task. This is the declaration of the task:

- task: PowerShell@2
  displayName: Pack Release
  inputs:
    targetType: filePath
    filePath: 'tools\packrelease.ps1'
    arguments: '-Configuration $(BuildConfiguration) -DestinationDir $(Build.ArtifactStagingDirectory) -StandardZipFormat $false -SkipZip $false -SkipConfigRename $false -compressionLevel 5'
    workingDirectory: 'tools'

As usual, you specify a task and the type — in this example, PowerShell@2. It is important to have the version after the @ character — it should be equal to the version of the task in the standard build, as shown in Figure 2.

Figure 2: Pay attention to the version of the task when you convert to a YAML build.

To figure out the input parameter name of the tasks (e.g. targetType, arguments, workingDirectory, etc), the most immediate solution is to look in the working directory of an agent and find the task definition.

Figure 3: Tasks inside the working folder of an agent.

Inside the folder of the chosen task, there are all the latest versions for any major version, and inside each version folder, there is a task.json file that can be inspected to see the exact version of the parameter.

After modifying the YAML build to use PowerShell tasks, the build started working as usual.