Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long Execution Time for dotnet restore in OpenShift Build Pipeline #13327

Closed
linhvuquach opened this issue Feb 27, 2024 · 4 comments
Closed

Long Execution Time for dotnet restore in OpenShift Build Pipeline #13327

linhvuquach opened this issue Feb 27, 2024 · 4 comments
Labels

Comments

@linhvuquach
Copy link

Impact

It's more difficult to complete my work

Describe the bug

During our build pipeline execution on OpenShift, we've encountered a significant delay specifically with the dotnet restore command in the Dockerfile. This delay is causing notable slowdowns in our overall build process.

My Dockerfile

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
ARG HTTP_PROXY="<my-url-local-proxy>"
ENV DOTNET_NUGET_SIGNATURE_VERIFICATION=false
WORKDIR /src
COPY ["My.API/My.API.csproj", "My.API/"]
COPY ["My.Application/My.Application.csproj", "My.Application/"]
COPY ["My.Infrastructure/My.Infrastructure.csproj", "My.Infrastructure/"]
COPY "My.API/nuget.config" .

RUN dotnet restore -v diag "./My.API/./My.API.csproj"
COPY . .
WORKDIR "/src/My.API"
RUN dotnet build "./My.API.csproj" -c $BUILD_CONFIGURATION -o /app/build

FROM build AS publish
RUN dotnet publish "./My.API.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .

ENTRYPOINT ["dotnet", "My.API.dll"]

My nugget.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
</configuration>
Version

I'm using openshift version 4.

Current Result
  • Local result: I can work fine with my Dockerfile in my local.
  • OpenShift result: The dotnet restore operation consistently takes 1-hour duration and seems to time out during the MSBuild within our OpenShift build pipeline.

Repro Steps

I can build a simple Dockerfile .NET API application. Then you can set up a simple trigger CI to Openshift to build the pipeline.

At the step build the pipeline you will face this issue (dotnet restore).

Expected Behavior

The Openshift pipeline can build successfully the Dotnet Docker image.

Screenshots

No response

Additional Context and logs

Additional Information
  • I saw a make sense information about NuGet signed-package verification dotnet restore takes too much time (docker dotnet/sdk:8.0) #13062 and additional ENV DOTNET_NUGET_SIGNATURE_VERIFICATION=false in Dockerfile. But it didn't resolve yet.
  • In my Dockerfile I also add a Proxy variable and use nuget.config file. You can look at it above.
  • I tried to create another Node simple application image. But it also stuck on the npm install step. I think the same concept with the dotnet restore command.
  • I'm always looking at my resource quota. I don't see CPU, memory,... reach limit:
    image
  • I also tried to change aspnet:8.0 to aspnet:7.0. It still didn't success

Any insights or guidance will be expected. Thank you for your attention to this matter.

@skofman1 skofman1 transferred this issue from NuGet/NuGetGallery Mar 15, 2024
@jeffkl
Copy link
Contributor

jeffkl commented Mar 20, 2024

Since it also seems to be slow for npm install, it sounds like something is up with the network connection? If your NuGet restore only includes a few projects and a few packages, it should be very fast. Perhaps you can troubleshoot the network connectivity? Can you try doing a trace route or ping from the docker machine?

@jeffkl jeffkl added the WaitingForCustomer Applied when a NuGet triage person needs more info from the OP label Mar 20, 2024
@linhvuquach
Copy link
Author

@jeffkl I try to ping the nuget.org during the Build step (in OpenShift pod) and I can get a result.

@dotnet-policy-service dotnet-policy-service bot added WaitingForClientTeam Customer replied, needs attention from client team. Do not apply this label manually. and removed WaitingForCustomer Applied when a NuGet triage person needs more info from the OP labels Mar 22, 2024
@jeffkl jeffkl added WaitingForCustomer Applied when a NuGet triage person needs more info from the OP and removed WaitingForClientTeam Customer replied, needs attention from client team. Do not apply this label manually. Triage:Untriaged labels Mar 22, 2024
@dotnet-policy-service dotnet-policy-service bot added the Status:No recent activity No recent activity. label Apr 7, 2024
@linhvuquach
Copy link
Author

After investigating, this issue isn't relevant to the Nuget. The cause of workload on OpenShift during dotnet restore. We can close this one.

@dotnet-policy-service dotnet-policy-service bot added WaitingForClientTeam Customer replied, needs attention from client team. Do not apply this label manually. and removed WaitingForCustomer Applied when a NuGet triage person needs more info from the OP Status:No recent activity No recent activity. labels Apr 9, 2024
@jebriede
Copy link
Contributor

@linhvuquach Thanks for providing an update. I'm glad to hear that you were able to identify the root cause. Closing ticket.

@dotnet-policy-service dotnet-policy-service bot removed the WaitingForClientTeam Customer replied, needs attention from client team. Do not apply this label manually. label Apr 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants