When you create a build pipeline you must sometime decide at runtime whether run some code or not. One of the options for this is output variables. It enables you to set a variable in one job and use this variable in the next job. In YAML we will write this in that way:
- stage: A
- job: JA
- script: |
echo "This is job Foo."
echo "##vso[task.setvariable variable=doThing;isOutput=true]Yes" #The variable doThing is set to true
- script: echo $(DetermineResult.doThing)
- job: JA_2
condition: eq(dependencies.JA.outputs['DetermineResult.doThing'], 'Yes')
- script: |
echo "This is job Bar."
Nowadays with Kubernetes being so popular, building a Docker image is a must thing for CI/CD pipeline. For this kind of pipelines, an artifact is not a simple zip file wich compiled application, but a Docker image pushed to container registry. There is plenty of benefits of this approach but there is also price for this. We need to handle this in our pipelines. Hopefully, this price is not high. And we will explore today how we can build a Docker image for our dotnet core web app on Azure DevOps.
Last time we created a gated check-in build for .NET Core app. It works very well, but we did there one thing which is in general a bad practice in our proficiency. We duplicated build steps for building and testing .NET Core app. We can do better than that, we can use templates. Following the documentation:
Templates let you define reusable content, logic, and parameters. Templates function in two ways. You can insert reusable content with a template or you can use a template to control what is allowed in a pipeline.
We will do both things.
Standard CI build checks integrity of committed code after merge. This approach can lead to a state when code is not deployable due to failing tests or even failing compilation. Gated check-in helps to protect the integrity by verifying state before the merge. In that way, you can protect your master branch and avoid build breaks. In that way, you can ensure that your master branch is always deployable (what is crucial in GitHub flow) and you will not interrupt your colleagues with your obvious mistakes. Gated check-in feature was originally introduced in TFS 2010. It can also be easily adopted in Azure DevOps YAML based builds.
The goal of Cache@2 task is improving build performance by caching files between pipeline runs. It supports multiple types of packages like
- Bundler gems
- npm packages
- Yarn packages
- NuGet packages
- Maven artifacts
- Gradle artifacts
- ccache artifacts
Further, we will focus on caching NuGet packages however in a similar manner we can configure this task for other types.