This is the fourth article in the series of Build Pipeline with Azure DevOps. Other articles in this series are:
1. Build Pipeline with Azure DevOps – The Basics 2. Build Pipeline with Azure DevOps – AppSettings.json Transformations 3. Build Pipeline with Azure DevOps – Generate EF Core Migration Script 4. Build Pipeline with Azure DevOps - Publish and Bundle Artifacts
- task: DotNetCoreCLI@2 displayName: "Publish" inputs: command: 'publish' publishWebProjects: true arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)' zipAfterPublish: false - task: PublishBuildArtifacts@1 displayName: "Upload Artifacts" inputs: pathtoPublish: '$(Build.ArtifactStagingDirectory)' artifactName: 'webapi-template-output' outputDirectorry: '$(System.DefaultWorkingDirectory)/'
The first step is basically equivalent of
dotnet publish --configuration release command. It puts all the published files in a special staging are in Azure DevOps called
$(Build.ArtifactStagingDirectory), it’s a different logical drive where different build outputs can be put together for bundling together later on. In this case we are publishing the web projects and sql migration (from previous article) in
The second step
- task: PublishBuildArtifacts@1 takes everything from the staging area and bundles them together and make them available for our Release pipeline.
The variables can used in this and previous articles can be defined on the top of the .yml file or in special Variables section on the top right corner as discussed in the AppSettings Transformations article.
Tip to see the values of your variables in the pipeline run output:
- task: PowerShell@2 inputs: targetType: 'inline' script: | # Write your PowerShell commands here. Write-Host "Hello System.DefaultWorkingDirectory" Write-Host '$(System.DefaultWorkingDirectory)' Write-Host "Hello Build.ArtifactStagingDirectory" Write-Host '$(Build.ArtifactStagingDirectory)' Get-ChildItem -Recurse
We can use inline PowerShell script to output the variables and see what they hold. It helps in debugging and understanding where the staging and published artifacts are going.
This marks the end of this series, we will discuss the Release Pipelines in separate series.