Resolving “TF401019: The Git repository with name or identifier xxxx does not exist or you do not have permissions for the operation you are attempting.” in Azure Pipelines git Submodule Checkout

Submodule in Git repos help you to keep the common code modules in a separate repo and utilize in multiple other repos. In the classic and YAML build pipelines you can checkout git submodules as explained in the post “Git Repo Submodule Checkout in Azure DevOps Build Pipelines”. However, you may encounter the below issue while running such build pipelines having to perform a git submodule checkout.

Cloning into 'D:/a/1/s/Infra/AzCLI'...

remote: TF401019: The Git repository with name or identifier InfraCLI does not exist or you do not have permissions for the operation you are attempting.

fatal: repository 'https://dev.azure.com/yourorg/DevOps/_git/yourrepo/' not found

fatal: clone of 'https://yourorg@dev.azure.com/yourorg/DevOps/_git/yourrepo' into submodule path 'D:/a/1/s/Infra/AzCLI' failed

Failed to clone 'Infra/AzCLI'. Retry scheduled

Azure Service Connection via Variable Group in YAML CD/Release Pipeline Templates

In application deployment we may use different Azure subscriptions to setup infrastructure for non-prod and production environment infrastructure most of the time. In classic release pipelines we could easily create a resource group to setup deployment task needs, which should be used in multiples stages/environments such as Dev, QA, staging or production. For such groups when the task group is using Azure App Service Deployment, Azure CLI tasks we could supply the service connection name via a variable that can be stored in a variable group relevant to the given stage/environment scope. In YAML we can use a template to define the common steps and it is ideal if we could refer to variable group, to hold the service connection information related to the relevant stage/environment. However, the possibility to use the variable group variable for service connection, regardless of whether using a template in YAML or Azure deploy steps used directly in pipeline YAML seems to be not working as expected. Let’s look at the problem and alternative solutions.

Resolving “Response status code does not indicate success: 400 (Bad Request)” in NuGet Packages Push to GitHub Packages with GitHub Actions

GitHub packages registry can be use to keep your organization NuGet packages privately or share them publicly. If you create a package in a private repo it would be private to the repo or for the organization if you use an organization. If you keep your packages in a public repo you can share it publicly. Ideally when you build reusable NuGet packages you would build and publish such packages with GitHub action workflow to your GitHub packages. While implementing this you may encounter “Response status code does not indicate success: 400 (Bad Request)” at the push of the package, due to special needs of GitHub based NuGet packages. Let’s look at them in this post.

Enhanced YAML Conversion for Azure DevOps Classic Build Pipelines

Azure DevOps YAML pipelines is the way to implement pipeline as code and version control the pipelines alongside your application code. However, among Azure DevOps users classic build pipelines are still popular due to its simple, visual ability to implement and understand faster etc. Additionally, classic pipeline agent job or individual step could be converted to YAML by using “View YAML” option available in each step/task as well as for a given agent phase. With a recent update to Azure DevOps new feature has been added to enable exporting entire classic build pipeline as YAML replacing the “View YAML” feature. This is a great improvement feature added to Azure DevOps as “View YAML” feature was only able to consider information in web UI when generating YAML out of classic pipeline, which at times generated incorrect YAML. With the new export YAML feature, now you can derive a reliable YAML implementation of a given classic pipeline. This would help people to implement pipeline quickly using classic pipeline UI and convert and obtain a YAML, which would help pipeline as code adoption easier. Let’s look at how we can use this new export to YAML feature.

Resolve the “Entity Framework tools version '3.1.9' is older than that of the runtime '5.0.0' in Visual Studio Package Manager”

.NET 5 is released recently and you can use entity framework core 5 with your projects by setting up the version 5.0.0 of the packages, Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.Design, Microsoft.EntityFrameworkCore.SqlServer, Microsoft.EntityFrameworkCore.Tools if you are using SQL server as the database. However, when you execute dotnet ef commands in the package manager console in Visual Studio you might see the message “Entity Framework tools version '3.1.9' is older than that of the runtime '5.0.0' in Visual Studio Package Manager”. Let’s see how we can get it fixed.

Deploying .NET 5 Web App via GitHub Actions to Azure App Service

.NET 5 is released recently and now you can develop applications using .NET. While releasing .NET five with zero delays Azure App Services started supporting .NET 5 with Early Access. This is helping us to deploy our application code, without having to deply them as self-contained with framework. Meaning we can now deploy our .NET 5 Web Apps, APIs or Function Apps to Azure, just as published project binaries and things will start to run without any issues. In this post let’s look at how we can setup a quick build deployment pipeline deploying a .NET 5 web application to Azure using GitHub Actions.

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.