Reduce application image build times with .NET Core incremental builds

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 true.

On my development machine, performing an s2i build for the dotnet new mvc-template gives these build times:

S2I Total time Restore time
First build 35s 16.5s
Successive build 24.5s 0.5s

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.

Red Hat OpenShift Container Platform can also be configured to perform incremental builds. Let’s look at the build time difference using a free Red Hat OpenShift Online account.

Free OpenShift Online account Total time Restore time
Non-incremental build 2m18s 28.5s
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
Non-incremental build 1m12s 12.72s
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

Conclusion

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 Linux containers or microservices Topic pages.

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.

For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Share