Avoid GitHub Action Workflow Code Duplication - Using Composite Actions to Create Reusable Templates

 Azure DevOps yaml files for piplines can be created as templates to avoid duplicating same set of tasks in multiple areas of the pipelines. For GitHub actions workflow, we have seen here in "Build and Unit Tests for .NET Apps with GitHub Actions" the same steps are repeated in both Windows and Linux, build and unit test run. The solution to avoid duplicating same steps in multiple jobs in a GitHub actions workflow is the usage of composite actions. Let's modify our workflow implemented in "Build and Unit Tests for .NET Apps with GitHub Actions" to use composite action to build and unit test, and reuse that in both Windows and Linux job.

Build and Unit Tests for .NET Apps with GitHub Actions

 Executing unit tests and viewing results in unit tests in a build pipeline is essential to keep high quality in an application deployment via any pipeline system. GitHub actions are the way forward to implement pipelines with repositories in GitHub. Let's explore how to run unit tests and view results in GitHub actions workflow.

Resolve Windows Docker Build "C:\Program Files\dotnet\sdk\6.0.407\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {7Bxxxxxxxxxxxx} failed due to the following error: 80040154 Class not registered (0x80040154 (REGDB_E_CLASSNOTREG))"

 Building .NET 6 project with Resource files is running into build issue as shown below, when building with .NET 6 nanoserver build images.

C:\Program Files\dotnet\sdk\6.0.407\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: The "GenerateResource" task failed unexpectedly. [C:\src\Demo\Demo.csproj]

C:\Program Files\dotnet\sdk\6.0.407\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {7Bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx} failed due to the following error: 80040154 Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)). [C:\src\Demo\Demo.csproj]

Resolving "There was a failure in sending the provision message: Unexpected response code from remote provider InternalServerError" in Azure DevOps Build Referring ACR

 Azure DevOps builds using ACR to push docker image may encounter error "##[warning]There was a failure in sending the provision message: Unexpected response code from remote provider InternalServerError" and would not be able to proceed to starting build job. Let's find the quick fix for it.

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.

Git Repo Submodule Checkout in Azure DevOps Build Pipelines

Submodule in Git repos help you to keep the common code modules in a separate repo and utilize in multiple other repos. When you clone the git repo you can include submodules by using git clone --recurse-submodules. In Azure pipelines you can enable checking out the code with submodules for build and package purpose. Let’s have a look at the settings to enable submodule checkout in builds.

Running EF Commands in Builds with .NET Core 3.1 in Hosted Agents

When you run builds with Entity Framework (EF) commands such as dotnet ef migrations script with .NET Core 2.2 it would work without any issue. However, if you upgrade your projects to use .NET Core 3.1 your build may fail with issue below., when executing dotnet ef migrations script, to generate a script out of your EF migrations.
error NETSDK1045: The current .NET SDK does not support targeting .NET Core 3.1. Either target .NET Core 2.2 or lower, or use a version of the .NET SDK that supports .NET Core 3.1.

Replacing iOS .plist Array Properties in Azure Release Pipelines

.plist files are used by iOS applications to keep configuration properties. These files support arrays as configurations. In deployment process of Azure DevOps pipelines you may want to update these plist files to have values relevant to the target deployment environments. Let’s see usage of plistbuddy utility to update array items in plist files as the plutil (http://scriptingosx.com/2016/11/editing-property-lists/) is unable to apply the changes.

Building Code from Multiple Repos with YAML Pipelines

You could only build code from a single repo using classic build pipelines in Azure DevOps. Now with multiple repo support added to YAML build pipelines (pipeline as code), you can decide which of the repos you want to checkout and build, in a single pipeline build sequence. Let’s see the steps in detail.

Resolving Azure DevOps Build Error “data at the root level is invalid” in dotnet test

When you try to execute dotnet test with test assemblies in Azure DevOps builds built with Visual Studio 2019 you may run into an error “data at the root level is invalid”. Let’s look at how to solve this issue and get the tests executed in the Azure DevOps build pipelines.

Build .NET Core 3.0 Projects with Azure DevOps Pipeline Using Hosted Agents

.NET Core 3.0 is still in preview 7 and some of you may have already started developing projects with it. Implementing CI/CD is important to any project regardless of whether you are using bleeding edge technology or not. It is possible to setup your own build server with the required preview components setup a builds. However, if you can utile the hosted agents in Azure DevOps Services that would remove the burden of maintaining your own build server. Hence, let’s look at the steps required to build a .NET core 3.0 application with hosted 2019 agents.

Controlling Pull Request Source Branches for Given Target Branch in Azure Git Repos

Generally you can create pull request from any given source branch to a any given target branch in Azure Git repos. You can setup a pull request validation build which evaluates the repo state, by performing a pre merge in the build server to ensure, your repo build succeeds after the pull request is merged to the target branch. You can set the branch policies so that the pull request cannot be merged to a given target branch if the validation build fails or if the approvers not approve the pull request. However, you might want to follow a branching strategy, which requires you to control from which branches a pull request can be created and merged to a targeting branch. The purpose of controlling the pull request source and target would be to assure your team is adhering to a defined branching and merge strategy. Let’s look at using a task in pull request validation build to ensure the request is coming from an allowed/valid branch, and make the build to fail if it is coming from an invalid branch.

Copying a Build Definition to Another Team Project in a Different Azure DevOps Organization

You can easily clone a build and create a new build definition in the same team project. This is useful when you have similar type of applications to be built. However, if you want to clone a build definition to another team project, or for that matter to a different Azure DevOps Organization, you cannot use the clone as it always creates it in the same team project. For task groups you can use import and export to get them copied over to a different team project or even to  a different team project in a different Azure DevOps organization. Let’s look at how to export and import a build definition from a team project into a different team project in a different Azure DevOps organization.

Deploying ASP.NET Core App to Azure Kubernetes Services (AKS)–Setting Up Azure DevOps Pipeline Manually–Step By Step Guide–Part 2

In the part 1 of this post, enabling Docker support for ASP.NET Core app and building and pushing the Docker image to Azure Container Service, using Azure DevOps build pipeline with simple steps was described. The image is tagged with the build Id and it is pushed to the Azure Container Registry, so that it can be later deployed to a container orchestrator to run the container. Helm is used to get he deployment done to AKS via Azure DevOps when creating a an ASP.NET Core App, Container Registry and AKS, then getting it deployed automatically with few clicks using Azure Projects as described in the post “Deploy ASP.NET Core App to AKS with Azure DevOps Project”. Let’s look at getting the container image in Azure Container Registry deployed to AKS with three simple steps without using Helm, with Azure Pipelines.

Deploying ASP.NET Core App to Azure Kubernetes Services (AKS)–Setting Up Azure DevOps Pipeline Manually–Step By Step Guide–Part 1

In the post “Deploy ASP.NET Core App to AKS with Azure DevOps” a quick start guide has been given on setting up an ASP.NET Core App with Azure DevOps projects. The application code, Azure Container Registry, Azure Kubernetes Service (AKS) Cluster as well as build and deployment pipelines were auto generated, with few clicks in the Azure Portal. To do deployment to AKS, Helm packaging was used in the Azure DevOps Projects auto generated sample app. In this post, let’s look at much simpler implementation, to get the ASP.NET Core App build and deployed to AKS via Azure Pipelines.

Updating Test Case Work Item Tags and Description based on Test Automation Code Test Category Attributes and Summary Descriptions

A test automation development team has come up with a requirement to keep track of some test automation code related attributes and documentation descriptions in the relevant Test Case work items in Azure DevOps. The documentation description added to each test method in  the code should be captured and updated to Test Case work item summary description. Any test category attribute values should be applied as Tags to the Test Case work item. Let’s look at how we can automate the above requirement using a little bit of PowerShell in combination with Azure DevOps build pipelines.

Custom Control Conditions in Azure DevOps Pipeline Steps

Azure DevOps pipelines support default conditions allowing you to execute a step “Only when all previous tasks have succeeded”, “Even if a previous task has failed, unless the build was canceled”, “Even if a previous task has failed, even if the build was canceled” or “Only when a previous task has failed”. These conditions facilitate execution of  steps in a build or release pipeline to cater different scenarios. However, to support scenarios not covered by the default conditions you can implement custom control conditions in Azure DevOps pipeline steps. There is a good explanation of custom conditions in this article. Let’s explore two advance scenarios that can be handled with custom conditions, which are not explained in the article.

Build and Deploy SSIS with Azure DevOps Pipelines

SQL Server Integration Services (SSIS) projects can be created to perform ETL (Extract Transform and Load) operations. As Implementing of Continuous Delivery becoming a mandatory aspect of any type of software project it is vital for SSIS projects to be able to implement CI/CD. With the availability of the extension “SSIS Build & Deploy” in Marketplace for Azure DevOps, the CI/CD implementation for SSIS has become straightforward to implement. Let’s look at a sample to understand how to get CI/CD implemented for SSIS project with Azure DevOps.

Making a Task Group Parameter Optional – Azure DevOps Pipelines

Task groups are really useful to share common actions with multiple build or release pipelines in Azure DevOps (VSTS). You can group multiple tasks ang create a task group forma build or release definition. then these task groups can be utilized in other build or release definitions in a given team project. Parameters in a task group help to pass values from build or release definition to the tasks in the task group. You can add a default value for these parameters or have to provide value from the build or release definition that is using the task group. Making a task group parameter optional is not straight forward and you need some do work around to get it working. Let’s look at how we can make a parameter optional for a task group in Azure DevOps pipelines.

Check if a Build Definition Exists for a Given Repo in VSTS/TFS

In scenarios where you have many teams working in the same team project, you might have multiple TFS Git repos within a single team project. When you want to create a build definition for a given repo, you might be wondering what if there is a build definition already exists for the repo. Opening each build definition to find that out is a waste of time. Let’s look at a small utility script that can give you the information quickly using VSTS/TFS REST API.