Obtaining Build Number, Build Id etc. of Another CI Build Pipeline in the CD/Release YAML Pipeline

Let’s look at how we can specify the artifact version to download based on the resource CI build linked to the CD pipeline and check on how to obtain the resource CI build pipeline information such as build number, build id definition id etc., in the CD YAML pipeline.

Implementing a CD YAML Pipeline with Deployment Job

We have discussed couple of things related to implementing CD with YAML in the posts “Trigger Deployment YAML Pipeline Once YAML Build Completed” and in “Prevent Checking Out the Repo in CD YAML Pipeline”. However, the checkout of the repo only happens if use the normal job syntax for deployment job as well. Ideally, we should be using job of type of “deployment” in our CD YAML pipelines so the checkout of repo would not happen by default as well as it will be required to define an environment for deployment. The environment helps us to keep track of our deployments. When we implement the CD YAML with deployment jobs download of artifacts would be automatic. Let’s find out how the deployment job implementation looks like.

Selecting Particular Source CI YAM Pipeline Build While Manually Triggering a YAML CD/Release Pipeline

In classic release pipelines in Azure DevOps you can pick which build to use in the linked build artifacts, easily at the create time. The new norm of implementing pipelines with Azure DevOps is becoming YAML way, allowing to keep your pipelines as code and version controlled. How to Separate CI and CD considerations to individual YAML pipelines was discussed in the post “Trigger Deployment YAML Pipeline Once YAML Build Completed”. Therefore, it is important to know how we can select a particular build, when we trigger a deployment/CD YAML pipeline manually. Let’s compare a classic pipeline triggering manually and YAML CD pipeline triggering manually to understand the difference.

Resolving “System.IO.IOException: The response ended prematurely.” in HttpClient Request

Some times a silly mistake can waste lot of time of a developer. The exception “System.IO.IOException: The response ended prematurely.” while making an http client request to call an API from another web app has wasted considerable amount of my time diagnosing the issue. Therefore, thought worth sharing the experience.

Prevent Checking Out the Repo in CD YAML Pipeline

In the previous post “Trigger Deployment YAML Pipeline Once YAML Build Completed” (https://chamindac.blogspot.com/2020/10/trigger-deployment-yaml-pipeline-from.html) we have discussed how to separate the deployment pipeline from the build pipeline, in Azure DevOps YAML pipeline implementations and to trigger a CD pipeline from the CI build once completed. However, if you check carefully that post implementation of CD it is still checking out the code repository, even though it is not necessary to checkout code being the deployment pipeline. Let’s see how we can avoid checking out repo in the CD YAML.

Trigger Deployment YAML Pipeline Once YAML Build Completed

Now it is possible to implement multi stage pipelines with YAML facilitating the implementation of deployment pipelines as well with YAML instead of classic release pipelines in Azure DevOps. However, having build and deployment steps all together in a single pipeline script is not ideal as it looks bit not a nice implementation from my point of view. With the possibility of triggering another YAML pipeline based on completion of another YAML pipeline, it is possible to separate the Build and Deployment concerns into two different YAML scripts implementing two different pipelines. Let’s have a quick look at how we can trigger a YAML deployment pipeline based on another YAML build pipeline.