Open othmane-kinane-nw opened 1 year ago
@dmitriy-pisarevskiy can you please provide reproduction steps ? Ideally with a repository.
@othmane-kinane-nw hey, seems I solved it yesterday. working example net 7 Dockerfile using buildx and arm64 platform.
As I understood need to add amd64 layer for restore packages like mcr.microsoft.com/dotnet/sdk:7.0-bullseye-slim-amd64 in this case subset with version 0.3.2 is working fine, at least my builds all green.
I use next command to compile project:
docker buildx build --platform linux/arm64 --file src/Web/WebStatus/Dockerfile --build-arg FW_GITHUB_TOKEN=usertoken --build-arg FW_GITHUB_USER=username src/
FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:7.0-bullseye-slim-amd64 AS prepare-restore-files
ENV PATH="${PATH}:/root/.dotnet/tools"
RUN dotnet tool install --global --no-cache dotnet-subset --version 0.3.2
WORKDIR /src
COPY . .
RUN dotnet subset restore "Web/WebStatus/WebStatus.csproj" --root-directory /src --output /src/restore_subset/
FROM mcr.microsoft.com/dotnet/sdk:7.0-bullseye-slim-amd64 AS build
WORKDIR /src
COPY "Ruby.sln" "Ruby.sln"
COPY --from=prepare-restore-files /src/restore_subset .
COPY "docker-compose.dcproj" "docker-compose.dcproj"
COPY "NuGet.config" "NuGet.config"
ARG TARGETARCH
ARG TARGETOS
RUN arch=$TARGETARCH \
&& if [ "$arch" = "amd64" ]; then arch="x64"; fi \
&& echo $TARGETOS-$arch > /tmp/rid
ARG FW_GITHUB_TOKEN
ARG FW_GITHUB_USER
ENV GITHUB_PACKAGE_TOKEN=${FW_GITHUB_TOKEN}
ENV GITHUB_PACKAGE_USER_NAME=${FW_GITHUB_USER}
RUN dotnet restore "Web/WebStatus/WebStatus.csproj" -r $(cat /tmp/rid)
COPY . .
WORKDIR "/src/Web/WebStatus"
RUN dotnet publish "WebStatus.csproj" --no-restore -c Release -o /app -r $(cat /tmp/rid) --self-contained false
FROM base AS final
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "WebStatus.dll"]
This appears to be a bug with NuGet running with QEMU (Quick Emulator). QEMU is being used here by Docker because you're running Arm64 on an x64 host machine.
In the meantime, let's talk about a workaround. You'll want to avoid emulation by not using a multi-arch tag for the sdk. To do this, you can use the 7.0-bullseye-slim-amd64 tag. You should only need to use that for the sdk stage of your Dockerfile. The final stage can still use the multi-arch tag (7.0).
But because you're explicitly using the amd64 version of the sdk image, you'll need to explicitly set the RID in the restore and publish commands. And because the RID is set you'll also need to disable the self-contained option if you don't want a self-contained deployment.
And there's one little gotcha with the architecture. In order to make it a truly multi-arch Dockerfile, you'd also need to account for when you specify --platform linux/amd64. In that case, the RID needs to use x64 not amd64, so there's some logic in the Dockerfile below which shows how to fix that up as well.
Note that in the Dockerfile below I make use of the TARGETARCH and TARGETOS arguments. You don't need to explicitly pass these arguments with the --build-arg option. They are automatically derived by using the --platform option. So you shouldn't need to change how you run the build command.
solved by downgrade to --version 0.3.1, seems something wrong with 0.3.2
Originally posted by @dmitriy-pisarevskiy in https://github.com/nimbleways/dotnet-subset/issues/6#issuecomment-1534159509