Replies: 2 comments 3 replies
-
|
It’s a best practice because each |
Beta Was this translation helpful? Give feedback.
-
|
I understand it skips the nuget layer. But in more complex solutions, especially mono-repos, there's numerous startup projects, nuget.config's, directory.build.props, and nuget lock files. The needed files for a nuget restore generally require far more than just the csproj, and this has a fantastic convenience associated to it since you don't have to track all those build assets in every unique startup project Dockerfile. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, using cache mounts for NuGet packages is a good solution and it can offer similar or better performance to using Docker's layer caching for local dev workflows. The benefit is amplified when you are building multiple projects that share dependencies. You can even cache .NET's build outputs like so: As for why it's not the default in the samples, I think it's a combination of:
We would happily take community contributions in this area (Issues or Pull Requests)! |
Beta Was this translation helpful? Give feedback.
-
|
Fantastic! I was unaware. I have been interested in helping contribute. If I were to open an issue/PR, would it be better side-by-side with the existing example dockerfiles or updating existing dockerfiles? I have some time next week to put something in if you're willing to provide a bit of guidance on where the samples belong! Side note, is there a particular reason you mention the context "local dev workflows"? We use this dockerfile setup in pipelines/deploys too and it works well. |
Beta Was this translation helpful? Give feedback.
-
If your build pipeline is just one project and one Dockerfile (as is the case for most of our samples), I think the cache mount provides limited benefit. If you get a clean build/CI machine when you build and deploy, then you'll be building the whole Dockerfile with an empty cache every time. Whereas, if you are developing your app locally and are repeatedly rebuilding the image, then you'll the build speed improvement. This is all assuming you haven't set up an external cache. Multi-project or multi-Dockerfile solutions will see the biggest benefit.
I think that we would want to update some or all of the existing Linux sample Dockerfiles. The |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've reviewed the different samples and most samples with Docker suggest putting the nuget restore into a separate build stage, copying only the *.csproj files to perform the restore.
However, I'm curious why it's done this way. I've found that simply declaring the global nuget caching folder as an explicit cache mount results in extremely similar build performance while simplifying the setup for multi-folder/multi-project solutions.
Is there a particular reason all the samples do that or is this perhaps another example to share with the community? We found this particular setup worked well for our fairly large project (20ish project references with a custom secured nuget repository). I did see this question was similar, but didn't offer the solution we ultimately landed on as an alternative approach: Previously posted question
Dockerfile example caching nuget without separating from publish:
Beta Was this translation helpful? Give feedback.
All reactions