In a previous article we explored how we can enforce code style in a solution with dotnet format --verify-no-changes.
Today we are discussing a rule that can be enabled in the .eidtorconfig file and potentially interfere with your local git settings so that dotnet format fails in the CI build but produces no errors locally.
Today is part 3 of our miniseries on dotnet publish and Docker images. In the first one we reviewed how we can generate docker images locally, in the second one we pushed our image to Azure Container Registry with Service Principal authentication from our local environment, and today we will publish our image to Azure Container Registry from our CI build, namely Bitbucket Pipelines.
In the previous article we explored how we can generate docker images of .NET applications and push them to the local Docker Desktop daemon.
Let’s now review how we can push a Docker image to a remote registry. We’ll be using Azure Container Registry as our destination, although the process is similar for all Docker Registries.
Docker is a very convenient tool for writing, testing and especially for deploying software. Wide adoption of Docker Containers by all Cloud Providers has made it the default approach for enterprise software deployments.
Historically we have been using a combination of Dockerfile and Docker CLI to build and publish docker images. Starting with .NET 7, we can achieve the same by using dotnet publish command.
Today we are exploring how to containerize a .NET application with dotnet publish, configure it inside .csproj file and publish to the local Docker Desktop.
We’ve all been there, editing bitbucket-pipelines.yml can be challenging. Bitbucket’s online validator is very handy, but it can produce false positives sometimes.
In this article, we take a look at bitbucket-pipelines.yml which passes Bitbucket’s validator but fails in the pipeline with This section should be a list (it is currently defined as a map). error. We also discuss tools that provide better local validation.