Making a cleaner and more intentional azure-pipelines.yml for an ASP.NET Core Web App

A few months back I moved my CI/CD (Continuous Integration/Continuous Development) to Azure DevOps for free. You get 1800 build minutes a month FREE and I'm not even close to using it with three occasionally-updated sites building on it.

It wasn't too hard, but as with all build pipelines you'll end up with a bunch of trial and error builds until you really get it dialed in.

I was working/pairing with Damian today because I wanted to get my git commit hashes and build ids embedded into the actual website so I could see exactly what commit is in production. How to do that will be the next post!

However, while tidying up we noticed some possible speed up and potential issues with my original azurepipeslines.yml file, so here's my new one!

NOTE: There's MANY ways to write one of these. For example, note that I'm allowing the "dotnet restore" to happen automatically as a sign effect of the call to dotnet build. Damian prefers to make that more explicit as its own task so he can see timing info for it. It's up to you, just know the side effects and measure!

Let's read the YAML and see what's up here.

• My primary Git branch is called "main" so my Pipeline triggers on commits to main.
• I'm using a VM from the pool that's the latest Ubuntu.
• I'm doing a Release (not Debug) build and putting that value in a variable that I can use later in the pipeline.
• I'm using a "runtime id" of linux-x64 and I'm storing that value also for use later. That's the .NET Core runtime I'm interested in.
• I'm passing in the -r $(rid) to be absolutely clear about my intent at every step.
• I want to build ONCE so I'm using --no-build on the publish command. It's likely not needed, but because I was using a rid on the build and then not using it later, my publish was wasting time by building again.
• The dotnet test command uses -r for results (dumb) so I have to pass in --runtime if I want to pass in a rid. Again, likely not needed, but it's explicit.
• I publish and name the artifact (fancy word for the resulting ZIP file) so it can be used later in the Deployment pipeline.

Here's the YAML

# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core



trigger:


- main



pool:


  vmImage: 'ubuntu-latest'



variables:


  buildConfiguration: 'Release'


  rid: 'linux-x64'



steps:


    - task: UseDotNet@2


      inputs:


        version: '3.1.x'


        packageType: sdk



    - task: DotNetCoreCLI@2


      displayName: 'dotnet build $(buildConfiguration)'


      inputs:


        command: 'build'


        arguments: '-r $(rid) --configuration $(buildConfiguration) /p:SourceRevisionId=$(Build.SourceVersion)'



    - task: DotNetCoreCLI@2


      displayName: "Test"


      inputs:


        command: test


        projects: '**/*tests/*.csproj'


        arguments: '--runtime $(rid) --configuration $(buildConfiguration)'



    - task: DotNetCoreCLI@2


      displayName: "Publish"


      inputs:


        command: 'publish'


        publishWebProjects: true


        arguments: '-r $(rid) --no-build --configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'


        zipAfterPublish: true



    - task: PublishBuildArtifacts@1


      displayName: "Upload Artifacts"


      inputs:


        pathtoPublish: '$(Build.ArtifactStagingDirectory)' 


        artifactName: 'hanselminutes'

Did I miss anything? What are your best tips for a clean YAML file that you can use to build and deploy a .NET Web app?

Sponsor: This week's sponsor is...me! This blog and my podcast has been a labor of love for over 18 years. Your sponsorship pays my hosting bills for both AND allows me to buy gadgets to review AND the occasional taco. Join me!