Since dotnet/sdk:8.0, dotnet restore takes too long on gitlab ci with docker

Are you experiencing extremely long dotnet restore times on GitLab CI with Docker after upgrading to .NET SDK 8.0? You're not alone. This issue has been reported by numerous developers, and it can significantly impact your CI/CD pipeline.

Fortunately, a workaround proposed by the NuGet team can help alleviate this problem. Here's how you can apply it:

1. Add the following lines to your .gitlab-ci.yml file:

   image: mcr.microsoft.com/dotnet/sdk:8.0-buster-slim
   
   before_script:
     - dotnet tool restore
   

   This ensures that the necessary NuGet tools are restored before running the dotnet restore command.

2. Use the --disable-parallel flag with dotnet restore:

   dotnet restore --disable-parallel
   

   This flag disables parallel restore, which can sometimes cause issues with large projects.

3. Consider using a different Docker image:

   image: mcr.microsoft.com/dotnet/core/sdk:8.0-buster-slim
   

   Sometimes, switching to a different Docker image can resolve the issue.

If you're still experiencing problems, you can also try the following:

• Increase the memory limit for your GitLab CI job.
• Use a GitLab runner with more resources.
• Contact GitLab support for assistance.

Remember, these are temporary workarounds. The underlying issue is being actively investigated by the NuGet team, and a permanent solution is expected in a future release of NuGet.

By following these steps, you can reduce the dotnet restore time on GitLab CI with Docker and keep your CI/CD pipeline running smoothly.