Specifying buildContext in Azure DevOps Pipeline (yaml) to Skirt Around Docker Copy Errors

Let’s call this “Technical Monday”, it doesn’t nearly have the ring to it as “Technical Tuesday”, but it is Monday and not Tuesday, and so “Technical Monday” is actually quite accurate although it has no poetic license whatsoever. As an architect, it’s important to keep some skin in the game and understand and be able to work with the technologies you are building out the architecture for – as an architect you may even need to build the PoC, and this might help you get things going. The target audience for this point would be for architects using .NET core and building out Docker architectures with Azure DevOps as well as engineers, and developers.

The example I’ll use is a .NET core Web API project which has been setup with a dockerfile in order to build the docker image. This assumes a standard .NET solution structure with a solution file at the root, and .NET projects in sub folders with a dockerfile in the same file location as the project file.

The dockerfile content as per below will build your docker image .

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
RUN mkdir app
COPY ./bin/Release/netcoreapp3.1/* /app/
EXPOSE 80
ENTRYPOINT ["dotnet", "/app/Inventory.Service.dll"]

Now, once you have your Pipeline setup in Azure DevOps, the docker build process will attempt to build your docker image, and it may fail if you haven’t properly configured your working directory as the build context.

To do this, edit your azure-pipelines.yaml file in Azure DevOps, and provide the following buildContext ./{project folder} where the project folder is the name of the folder that your project resides in.

input:
buildContext: ./Inventory.Service

When Azure DevOps builds your docker image using the command in your dockerfile, it makes a copy of the build project files in a temporary location such as the following:

/var/lib/docker/tmp/docker-builderXXXXXXXXX/

However, even though the docker build worked locally, the build will likely fail on the copy command because your contents are actually one level deeper in your project folder and this folder is not set to the default folder by default. By providing the proper buildContext you can skirt around the issue without having to make any breaking changes to your projects dockerfile or project structure.