DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Coding
  3. Languages
  4. Converting PowerShell Tasks in YAML

Converting PowerShell Tasks in YAML

YAML builds allow you to save time and automate more. Let's explore the best wats to use PowerShell tasks in YAML to expedite your workflows.

Ricci Gian Maria user avatar by
Ricci Gian Maria
·
Aug. 17, 18 · Tutorial
Like (1)
Save
Tweet
Share
10.83K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Task (computing) PowerShell Build (game engine) YAML

Published at DZone with permission of Ricci Gian Maria, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Choosing the Right Framework for Your Project
  • Building a RESTful API With AWS Lambda and Express
  • Using GPT-3 in Our Applications
  • OpenVPN With Radius and Multi-Factor Authentication

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: