在 Visual Studio 中使用相同的 docker 文件构建 docker 映像的 Azure Pipeline 失败

Question

I'm trying to create a deployment pipeline to deploy my image to Kubernetes cluster. The first step in this process is to create an image based on the docker file. The docker file I'm using was generated from Visual Studio when I added docker support and successfully creates the image when right clicking on the docker image and selecting to create it. When I configure the Azure Pipeline, the create docker image fails as soon as it tries to build the actual solution. The previous step grabs all the sources files but then fails on the docker image creation with

[error]COPY failed: stat/var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj:
 no such file or directory

[error]/usr/bin/docker failed with return code: 1

The following is the docker file generated from Visual studio and is referenced by the azure pipeline stage to create the docker image.

 FROM mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim AS base

 WORKDIR /app   
 FROM mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS
 build 

 WORKDIR /src      
 COPY ["DockerTest/DockerTest.csproj", "DockerTest/"]      
 RUN dotnet restore "DockerTest/DockerTest.csproj"      
 COPY . .      
 WORKDIR "/src/DockerTest"      
 RUN dotnet build "DockerTest.csproj" -c Release -o /app  

 FROM build AS publish      
 RUN dotnet publish "DockerTest.csproj" -c Release -o /app

 FROM base AS final      
 WORKDIR /app      
 COPY --from=publish /app .      
 ENTRYPOINT ["dotnet", "DockerTest.dll"]

##[section]Starting: Build a container image
============================================================================== Task: Docker Description : Build, tag, push, or run Docker images, or run a Docker command. Task can be used with Docker or Azure Container registry. Version : 0.150.6 Author : Microsoft Corporation Help : [More Information] https://go.microsoft.com/fwlink/?linkid=848006 )
============================================================================== [command]/usr/bin/docker build -f
/home/vsts/work/1/s/DockerTest/Dockerfile -t ihacontainers.azurecr.io/dockertest:6 /home/vsts/work/1/s/DockerTest Sending build context to Docker daemon 6.144kB Step 1/15 : FROM mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim AS base 2.2-stretch-slim: Pulling from dotnet/core/runtime 743f2d6c1f65: Pulling fs layer 074da88b8de0: Pulling fs layer ac831735b47a: Pulling fs layer 3adcc844418d: Pulling fs layer 3adcc844418d: Waiting ac831735b47a: Download complete 743f2d6c1f65: Verifying Checksum 743f2d6c1f65: Download complete 074da88b8de0: Verifying Checksum 074da88b8de0: Download complete 3adcc844418d: Verifying Checksum zadcc844418d: Download complete 743f2d6c1f65: Pull complete 074da88b8de0: Pull complete ac831735b47a: Pull complete 3adcc844418d: Pull complete Digest: sha256:066c31b113b0a20e6155d3bd8a314563c688d2ec31c11d7e551af5bc2595f30c Status: Downloaded newer image for mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim ---> c0f9ab44ecc1 Step 2/15 : WORKDIR /app ---> Runni ng in 6d1a5f5600dd Removing intermediate container 6d1a5f5600dd ---> 527fcebeaf1f Step 3/15 : FROM mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS build 2.2-stretch: Pulling from dotnet/core/sdk c5e155d5a1d1: Pulling fs layer 221d80d00ae9: Pulling fs layer 4250b3117dca: Pulling fs layer 3b7ca19181b2: Pulling fs layer 3466298fc231: Pulling fs layer 310737d73ed1: Pulling fs layer dc981de74fae: Pulling fs layer 3b7ca19181b2: Waiting 3466298fc231: Waiting 310737d73ed1: Waiting dc981de74fae: Waiting 4250b3117dca: Verifying Checksum 4250b3117dca: Download complete 221d80d00ae9: Verifying Checksum 221d80d00ae9: Download complete 3466298fc231: Verifying Checksum 3466298fc231: Download complete c5e155d5a1d1: Verifying Checksum c5e155d5a1d1: Download complete 3b7ca19181b2: Verifying Checksum 3b7ca19181b2: Download complete c5e155d5a1d1: Pull complete 221d80d00ae9: Pull complete 310737d73ed1: Verifying Checksum 310737d73ed1: Download complete 4250b3117dca: Pull complete dc981de74fae: Verifying C hecksum dc981de74fae: Download complete 3b7ca19181b2: Pull complete 3466298fc231: Pull complete 310737d73ed1: Pull complete dc981de74fae: Pull complete Digest: sha256:222cc0bb0bc93875ee0f6be626b2838beea838f65e53653e07c33eb9d00b0163 Status: Downloaded newer image for mcr.microsoft.com/dotnet/core/sdk:2.2-stretch ---> e4747ec2aaff Step 4/15 : WORKDIR /src ---> Running in a7ebcac87f68 Removing intermediate container a7ebcac87f68 ---> d7541674a9da Step 5/15 : COPY ["DockerTest/DockerTest.csproj", "DockerTest/"] COPY failed: stat /var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj:no such file or directory

##[error]COPY failed: stat/var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj:no such file or directory

##[error]/usr/bin/docker failed with return code: 1 ##[section]Finishing: Build a container image

Answer 1

I solved the issue by setting the buildContext to '$(Build.Repository.LocalPath)' using the same dockerfile as in Visual Studio without adjusting the paths:

In YAML-Konfiguration, I added the following line:

buildContext: '$(Build.Repository.LocalPath)'

Answer 2

[error]COPY failed: stat/var/lib/docker/tmp/docker-builder158012929/DockerTest/DockerTest.csproj: no such file or directory

According to this error message, the error occurred on the line of your dockerfile: COPY ["DockerTest/DockerTest.csproj", "DockerTest/"] .

First, please confirm that you did not use .dockerignore file to exclude this file: DockerTest/DockerTest.csproj , which must exists in the directory where you run your build from.

If it does not ignored by .dockerignore file, then you need to consider about your dockerfile location level.

DockerTest.csproj file should not put at the lower source file path level. You need to change the source of the context, move it at a higher level. So modify your dockerfile manually as :

COPY ["DockerTest.csproj", "DockerTest/"]

Answer 3

This problem is arise when you generate the Docker support via Visual Studio (v16.3.9 at least) and you are using this generated project in the Azure Pipeline with the predefined Docker pipeline template either in old-fashioned everything-to-click way so called the classic editor or the new 4-step easy-to-click way so called the modern editor .

The change in the generated file from

COPY ["DockerTest/DockerTest.csproj", "DockerTest/"]

to

COPY ["DockerTest.csproj", "DockerTest/"]

solve the problem with the Azure Pipeline but it will break your local build within the Visual Studio.

Adding

buildContext: '$(Build.Repository.LocalPath)'

to the YAML file which has been generated by the modern editor will break the build task. The template which is used in the modern editor relies on the default build context and the parser will not recognise the buildContext command.

Only possible way how to fix this problem is to override the default build context . This override will keep the build functionality either in Visual Studio or the Azure Pipeline.

The build context can be overridden in the build image task in the classic editor.

Answer 4

For me it worked with following yaml settings

steps:

• task: Docker@2

  displayName: Build docker

  inputs:

  command: 'buildAndPush'

  Dockerfile: '**/Dockerfile'

  buildContext: '$(Build.Repository.LocalPath)'

The dockerfile can stay as Visual Studio generated it.

Answer 5

In my case, I had the following folder structure:

+-- [REPOSITORY FOLDER]
|   +-- [SOLUTION FOLDER]
|   |   +-- [*.SLN]
|   |   +-- [PROJECT Folder]
|   |   |   +-- [*.CSPROJ]
|   |   |   +-- [dockerfile]

My docker file is inside the project folder.
After modifying to use only the CSPROJ file in the first copy, and receiving the missing MAIN method error, not having a suitable static main entry point, I fixed it replacing the "copy .." to "COPY . [project_name]/"

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["SampleApi1.csproj", "SampleApi1/"]
RUN dotnet restore "SampleApi1/SampleApi1.csproj"
COPY . SampleApi1/
WORKDIR "/src/SampleApi1"
RUN dotnet build "SampleApi1.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "SampleApi1.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "SampleApi1.dll"]

Answer 6

Try moving your Dockerfile to the root, alongside the .sln file.

None of the other answers worked for me, it would never find the project paths to the csproj files.

My project only contains one project that needs to be containerized, and some support dll projects, so I moved the original Dockerfile created by Visual Studio into the root, alongside the .sln file, and our pipeline built the image and deployed it to our ACR no problem.

I think the other solutions, if they work for you, are better, but if not, and it will work in your situation, give this a shot.