Reduce application image build times with .NET Core incremental builds
In a previous article, we talked about using containers to build .NET Core application images to make our builds portable and reproducible. Because each build starts from scratch, some time is spent downloading and extracting NuGet packages.
One way to reduce build times is to add a local NuGet server; this brings packages closer to the build machines, which reduces the time to download the packages. In this article, we’ll look at how the new incremental build feature of the .NET Core S2I builder can further reduce build times.
The .NET Core S2I builder now supports incremental builds. When we do an incremental build, the builder will reuse the NuGet packages from a previously built application image. So, the first build of the application image will fetch packages from the NuGet server, and successive builds will reuse those packages.
To perform incremental builds using the source-to-image (
s2i) tool, we need to pass the
--incremental flag. By default, the .NET Core S2I builder will remove NuGet packages to reduce the size of the application image. To keep those packages around, we need to set the
DOTNET_INCREMENTAL environment variable to
On my development machine, performing an
s2i build for the
dotnet new mvc-template gives these build times:
|S2I||Total time||Restore time|
We see the build time goes down thanks to the reduced restore time; however, the total time doesn’t go down by the same amount. This is because we spend extra time to extract the NuGet packages from the previous application image. Note that the previous application image is already present on the build machine, so we spend no time fetching it from an image registry.
|Free OpenShift Online account||Total time||Restore time|
|Successive incremental build||4m45s||2s|
In this case, the incremental build is slower. Fetching packages from the NuGet server is faster than retrieving the previously built application image from the cluster container image registry and then extracting the packages from it.
Let’s do this again. Now we’ll use an on-premise Red Hat OpenShift test cluster. These are the build times:
|OpenShift test cluster||Total time||Restore time|
|Successive incremental build||1m53s||1s|
The build times are closer, but again, the non-incremental build is faster thanks to the high bandwidth to the NuGet server compared to the container registry.
Everything you need to grow your career.
With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.SIGN UP
In this article, we looked at the new incremental build feature of the S2I .NET Core builder. When using
s2i on a developer machine, the incremental builds are faster when a previously built application image is already present on the machine. This is not the case when building on OpenShift. It depends on the bandwidth to the cluster image registry compared to the bandwidth to the NuGet server whether incremental or non-incremental builds are faster.
To learn more, visit our Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets (e.g. containers), books (e.g. microservices), and product downloads that can help you with your microservices and/or container application development.