Azure DevOps YAML cheat sheet

Working with YAML in Azure DevOps, and always forgetting the syntax? Search no further!

Photo by Etienne Girardet on Unsplash

For a couple of years YAML is used by Azure DevOps to define pipelines. Before YAML I used the classic editor, but I find it useful to include a build script in source control. On the other hand, I noticed that it is difficult to memorize all commands. In this article I will explain some commonly used commands when building .NET (Core, 5, 6) projects.

Agents and pools

In order to run a pipeline an agent pool is required. An advantage of Azure DevOps is that you can use Microsoft-hosted agents (MS Docs).

pool:
  vmImage: ubuntu-latest

Trigger (continuous integration)

Use the trigger command to set up CI for a branch or specific branches (MS Docs).

trigger:   
  main

Global variables

Variables are used to define values that can be used in pipelines (MS Docs).

variables:
  buildConfiguration: 'Release'

Stages, Jobs, Steps and Tasks

These terms refer to the hierarchy of YAML (MS Docs):

• Stage: a collection of jobs.
• Job: a collection of steps run by an agent or on a server.
• Step: a linear sequence of operations, such as tasks or scripts.
• Task: a building block of a pipeline.

NuGet tool installer

Use this task to install a specific version of NuGet in your pipeline (MS Docs).

- task: NuGetToolInstaller@1

Use a specific .NET version

This task is used to acquire a specific version of .NET (Core, 5, 6) (MS Docs).

- task: UseDotNet@2
  version: '6.0.x'

Restore packages

When your project depends on NuGet packages, add a restore command (MS Docs):

- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

Build your project

Use this command to build your project (MS Docs). Because an implicit restore task is used (see previous paragraph), I added the --no-restore argument.

- task: DotNetCoreCLI@2
  inputs:
    projects: '**/*.csproj'
    arguments: '--configuration $(BuildConfiguration) --no-restore'

Run tests

In order to run tests, your unit-test project should reference (MS Docs):

• Microsoft.Net.Test.Sdk
• A test framework, e.g. xunit
• A test runner, e.g. xunit.runner.visualstudio

- task: DotNetCoreCLI@2
  displayName: 'Run unit-tests'
  inputs:
    command: 'test'
    projects: '**/*[Tt]ests.csproj'    
    arguments: '--configuration $(BuildConfiguration)'

Code coverage

Code coverage results can be collected by using a coverage framework. In this example I use Coverlet. Make sure to add a reference in your unit-test project to Coverlet or another coverage framework.

The test command now looks as follows:

- task: DotNetCoreCLI@2
  displayName: 'Test'
  inputs:
    command: 'test'
    projects: '**/*[Tt]ests.csproj'
    publishTestResults: true
    arguments: '--configuration $(BuildConfiguration) /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura'

And use the following task to publish the results. I used Cobertura to calculate the coverage.

- task: PublishCodeCoverageResults@1
  displayName: 'Publish code coverage results'
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '**/*coverage.cobertura.xml'

When a build has finished, see the “Code coverage” tab in the build summary to view the code coverage results.

Azure DevOps code coverage results

Run tests under a specific Azure subscription

Sometimes tests need to access Azure resources. This is often the case for UI or system tests. The following tasks runs the dotnet test command under a specific Azure subscription.

- task: AzureCLI@2
  displayName: 'Run UI or system tests'
  inputs:
    azureSubscription: 'my-azure-subscription'
    scriptLocation: inlineScript
    scriptType: pscore
    inlineScript: |
      dotnet test <args>

Create a package

When your project will be used as a package, the first step is to create the package (MS Docs). The following task creates a pre-release version.

- task: 
  DotNetCoreCLI@2
  inputs:
    command: 'pack'
    packagesToPack: '**/MyProject.Library.csproj'
    packDirectory:
'$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)'
    versioningScheme: 'byPrereleaseNumber'
    majorVersion: '1'
    minorVersion: '0'
    patchVersion: '$(Build.BuildId)'

Publish a package

A package can be published on an Azure Artifact feed (MS Docs).

- task: DotNetCoreCLI@2
  inputs:
    command: 'push'
    packagesToPush: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/*.nupkg'
    publishVstsFeed: 'my-feed'

All together

When using all the tasks together, the YAML looks as follows:

Further reading

Configuring CI/CD Pipelines as Code with YAML in Azure DevOps