The Build Packages which is packaged as webdeploy and deployed to Azure App service using Kudu, only have the read access . However, If you want to change content using kudu of Azure app service or stop/start a web job, you would not be able to do so due to not having wright permission. This blog explains how to enable read write permission to content in an app service deployed using a web deploy package.
You would be able to see the read only mode message similar to following image.
When building a .NET Web App with /p:WebPublishMethod=Package build argument to package as a web deployment package, the package is created with a folder structure where all the dll files are located in inner subfolder. If we use Azure DevOps Windows agents, We can deploy these packages using msdeploy.exe to correct path of Azure App service without worrying about the folder structure of the build package. However, If we use Azure DevOps Linux agents to deploy, it deploys packages with kudus copy and copying the inner folder structure to wwwroot. Then the App service will fail to run the .NET web application. This blog explains how to correctly deploy a .NET Web App built with Windows as a web deployment package using Azure DevOps Linux agents.
Web deployment package would create a folder hierarchy such as below. If we deploy below package using Linux agent, it will copy content folder with the all the sub folders to the wwwroot of the App service making the app to not runnable.
This blog explains how to configure chef infra server in WSL2 in Windows 10/11.
Prerequisites:
Let's get started,
sudo dpkg -i chef-server-core-<version>.deb
Azure DevOps wikis supports Mermaid syntax that can be used to draw diagrams such as flow charts, UML diagrams, pie charts, Gantt charts and many more.
This blog explains mermaid syntax sample in Azure DevOps
() - rounded rectangle
{} - diamond
[] - rectangle
When using an Azure DevOps deployment pipelines with exclusive lock for a stage and triggering a deployment pipeline parallelly, only the latest deployment runs and all previous deployments that triggered automatically get cancelled. This would be fine with cumulative deployments, however, if you have a different content in each deployment run, canceling the one deployment affect the system badly due to missing updates to the system.
Following image shows, pipeline automatically cancelled the previous run and runs only the latest deployment.
When working with YAML pipelines, we can define pipeline trigger options such as branch triggers and path filters. However, there was a limitation to set path filters before. The path filters cannot have wild cards. However, now Azure DevOps supports wild cards in path filters in YAML pipelines as explain in this blog.
Pre-requisite: Repo with a code solution
Following is the project structure we are going to use for the path filter. Once add a change to one of the cshtml files, sample YAML pipeline use in this blog should be triggered automatically.
Automated processes failing from the intermittent issues (due to connectivity failures etc.) is one of the main challenges you might face while automating build and releases using CI/CD tools. Azure DevOps has introduced new task retry feature as a solution to intermittent failures. You can retry only the failed task multiple times without requeue entire pipeline. This blog is explaining how to use retry in Azure DevOps pipelines.
Following is a PowerShell task in a pipeline which is generating random number and mark task as success if the random number is even, otherwise failing the task with an exception. we have to setup number of retried to enable the feature of retrying on a task failure.
