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