Creating reusable build scripts with NUKE components
Tags: nuke, ci, csharp
Published: 2021-07-28 14:07:39

When your application landscape expands, doing CI/CD becomes a challenge. Applications need to be built, tested, and deployed, and then tested again. Typically, each application is a bit of a snowflake in some way; it’s built in a slightly different way, or some tests need to be excluded, or publishing is more involved than with others. Maintaining CI/CD pipelines becomes a chore, and problems that arise tend to eat up a lot of time.

In this situation, it can be beneficial to simplify things a bit. In our case (that case being Coolblue), almost all applications have a three-stage build pipeline:

<ul>
<li><p><strong>Pull Request</strong></p><p>This is executed each time a pull request is made or updated; it builds the application and runs unit and integration tests.</p></li>
<li><p><strong>Build Release</strong></p><p>This is executed each time a change is merged (or pushed) to the main branch; it also builds the applications and runs unit and integration tests, but it also prepares the application to be deployed–this means packaging the application, uploading it to our deployment system, and associating some metadata with it.</p></li>
<li><p><strong>Release</strong></p><p>This is executed after the previous step completes successfully, and deploys the application to one of the environments. If the environment is the last one before production, it also runs automated acceptance tests.</p></li>
</ul>

For each stage of the pipeline, there’s only one step: execute a PowerShell script called `build.ps1`, which is always located in the root of the application’s repository, and pass it some strictly defined arguments. These argument always include the ‘target’, or ‘what to do’, and, depending on the stage, arguments like ‘which environment’ and so forth.

If an application needs to do something special, it can almost always be solved by just modifying this PowerShell script. The CI/CD pipelines become static and can be created at the click of a button.

## Cake
Of course, only the most simplistic applications can get away with a build script as simple as `dotnet publish` and `dotnet test`. Deploying an application already involves using external tooling to be able to communicate with the deployment system. In addition, our build scripts do things beside building and testing, like:

* Adding build metadata, like when an application was built, and from which Git commit.
* Setting up secrets to be able to run integration tests against a live database, or to be able to send authenticated requests to a deployed application.
* Notifying the team when the application fails to build, tests fail, or when a deployment fails.

While this *can* be done in PowerShell, it’s not the easiest language to use, and not everyone is well versed in it.

Enter Cake.

For those not familiar with it, [Cake](https://cakebuild.net) is a build automation system with a C#-based <abbr title="Domain-Specific Language">DSL</abbr>. It is based on the concept of [tasks](https://cakebuild.net/docs/writing-builds/tasks/), which are small units of work, like restoring packages, building, or testing, which can have dependencies on, or trigger, other tasks.

For example:
```csharp
Task("PullRequest")
    .IsDependentOn("Build")
    .IsDependentOn("Test");

Task("Build")
    .Does(() =>
          {
              DotNetCoreBuild("MyApplication.sln");
          });

Task("Test")
    .Does(() =>
          {
              DotNetCoreTest("test/MyApplication.Tests/MyApplication.Tests.csproj");
          });

RunTarget("PullRequest");
```

This will run the `PullRequest` task, which is dependent on `Build` and `Test` (in that order), so it will run `dotnet build MyApplication.sln` and `dotnet test test/MyApplication.Tests/MyApplication.Tests.csproj`.

So where does `build.ps1` come in? Well, you can’t just run a Cake script; you need a runner. The `build.ps1` script’s job is to bootstrap this. It downloads the Cake runner from NuGet and invokes the runner, which will then compile and execute the Cake script.

## Bad Cake
Cake is a very nice system, but there are some problems when using it at scale, as we do.

Because Cake is not ‘pure’ C#, but rather a C#-based DSL, enhanced with some additional features, there’s no _good_ editor support. Some editors, like Visual Studio Code, [support syntax highlighting](https://marketplace.visualstudio.com/items?itemName=cake-build.cake-vscode), but IntelliSense is limited to the default ‘hey I’ve seen this symbol before but it might not be appropriate in this context’ version[^1]. Because of this, the feedback loop is very cumbersome: edit a file, run `build.ps1`, get a syntax error, fix it, rinse and repeat.

It does not help that Cake’s primary building block, the task, is ‘stringly typed’. Task names are always expressed as strings. That means that if you mistype the name of a task somewhere, you won’t know until you run the build. Navigating to a particular target is also notoriously cumbersome.

Cake’s [API for dealing with file system paths](https://cakebuild.net/api/Cake.Common.IO.Paths/ConvertableFilePath/) is well-meant, but because it is not consistently applied, it frequently means you have to convert to and from strings, and between ‘convertable paths’ and ‘actual paths’. This is a major source of compilation errors, again because there’s no proper editor support.

Finally, one of the biggest issues is that reusing code is not made very easy. You can write NuGet packages to extend Cake, but as far as I’m aware those cannot define new tasks. You can also package one or more Cake scripts into a NuGet package, but this is again cumbersome (as you have to mess about with `.nuspec` files), and as far as I’m aware, this also doesn’t let you define tasks.
## NUKE
All of these issues were encountered relatively recently when I had to make changes to a Cake script. The way Cake scripts have evolved within our organization is that some people have invested some time into creating a single set of Cake scripts that does almost everything we want. That set of scripts was then massively copied and pasted into other projects. Over time, some scripts gained new abilities, but because there was no proper way of sharing them back to the origin or all of its clones, each build script becomes a snowflake. The result is that the mental load of modifying Cake scripts is massive, because you need to account for a specific script’s peculiarities and limitations.

It was at that point I started searching for an alternative. I quickly ran into another build automation system that I’d heard of before, but never really used: [NUKE](https://nuke.build). [Dennis Doomen](https://www.continuousimprover.com) (also known as ‘the guy who wrote [FluentAssertions](https://fluentassertions.com)’) had written [a very nice article outlining why he thought it was a great replacement](https://www.continuousimprover.com/2020/03/reasons-for-adopting-nuke.html). He outlines more reasons, but NUKE specifically addresses all of the issues I was having with Cake.

* It is ‘normal’ C# in a normal project in your solution, which means you get the benefits of IntelliSense, or Smart Completion, or whatever your editor calls it.
* Targets (the NUKE equivalent of Cake’s tasks) are regular C# symbols (either fields or properties), which means the compiler and your editor are aware of when you mistype a name and can point this out to you.
* The file system and path API is excellent, although it still looks weird when you see the ‘division’ operator being overloaded to construct paths (`Root / "src" / "MyApplication" / "MyApplication.csproj"`).
* You can reuse code by using NuGet packages, just like in regular projects.

The Cake example from before looks like this in NUKE:

```csharp
class Build: NukeBuild
{
  public static int Main() => Execute<Build>(x => x.PullRequest);

  [Solution]
  Solution Solution;

  Target PullRequest =>
    _ => _.Triggers(Build)
          .Triggers(Test);

  Target Build =>
    _ => _.Executes(
      () => DotNetTasks.DotNetBuild(o => o.SetProjectFile(Solution))
    );

  Target Test =>
    _ => _.Executes(
      () => DotNetTasks.DotNetTest(o => o.SetProjectFile(Solution))
    );
}
```

## Reusability
So how does one reuse code in a NUKE build script? Let’s say we want to reuse a target, like publishing in Release mode for the `win10-x64` runtime while treating warnings as errors.

Since the build class needs to contain all the supported targets, composition is not an option. The only option left, then, is to introduce a base class.

```csharp
abstract class MyBuild: NukeBuild
{
  Target Publish =>
    _ => _.Executes(() => { /* publish code goes here */ });
}

class Build: MyBuild
{
  Target BuildRelease =>
    _ => _.Triggers(Publish);
}
```

Because of inheritance, the `Build` class now exposes two targets: `Publish` and `BuildRelease`. Job done, right? Well, not so fast. What about optional features? For example, not all of our projects have automated acceptance tests. If every build exposed a target for running acceptance tests, you’d have no idea whether that target is there because of the base class or because it actually does something useful.

Of course, we could define a base class for ‘build _without_ acceptance tests’ and ‘build _with_ acceptance tests’, but that only works for the one feature. If you have multiple optional features that are not mutually exclusive, then you end up having to create many different subclasses for all the different combinations. If you have _n_ number of optional features, the number of subclasses you have to create (and maintain) is _2<sup>n</sup>_. For two features, that’s 4 classes; for three features, 8 classes, and for four features it adds up to 16 classes. You’ll also have a lot of code duplication, because you can’t inherit from anything (otherwise you’d end up with the same problem you were trying to solve). You can see why this isn’t a great idea.
## Default interface implementations
Fortunately, NUKE’s got you covered. The solution is... _(drum roll)_ multiple inheritance! Great, but C# doesn’t have multiple inheritance. Well, since C# 8.0, it kind of does.

C# has technically always supported multiple inheritance, using interfaces. Originally, this meant that you could only ‘inherit’ multiple contracts, but not actual behavior. That’s where [default interface implementations](/c-sharp-7-2-and-8-0-uncertainty-awesomeness/#default-interface-implementations-c-8.0) come in. Introduced in C# 8.0, it allows any interface member to have a default implementation. An implementing class (or struct) does not need to provide an implementation for that member, although it is allowed to, in order to override the default behavior.

One of the examples of this I like, which was also used in a [video where Mads Torgersen explains C# 8.0’s new features](https://youtu.be/VdC0aoa7ung?t=715), was that of a logger. A typical logger interface has members like `LogDebug`, `LogInformation`, `LogError`, and so forth. It’ll usually also have something like a `Log` or `Write` method, which has the same parameters, preceded by a ‘level’ parameter. The implementation of `LogDebug` and similar methods is usually to call that `Log` method with the respective log level.

```csharp
enum LogLevel
{
  Debug,
  Information,
  Warning,
  // etc.
}

interface ILog
{
  void Log(LogLevel level, string message);
  void LogDebug(string message);
  void LogInformation(string message);
  // etc.
}

class Log: ILog
{
  public void Log(LogLevel level, string message) { /* omitted for brevity */ }

  public void LogDebug(string message) => Log(LogLevel.Debug, message);
}
```

_Every_ implementation of `ILog` needs to implement `LogDebug` and friends, even though that implementation will likely be exactly the same as the existing ones.

With default interface implementations, the default implementation of these methods can be provided in the interface:

```csharp
interface ILog
{
  void Log(LogLevel level, string message);
  void LogDebug(string message) => Log(LogLevel.Debug, message);
  void LogInformation(string message) => Log(LogLevel.Information, message);
  // etc.
}
```

Now the only thing an implementation of `ILog` **needs** to implement is the `Log` method. This also means that you can add new methods to the interface without breaking existing implementations.

## NUKE build components
So how does all of this help us with the problem of supporting optional features in our NUKE build script? NUKE calls this concept ‘[build components](https://nuke.build/docs/sharing-builds/build-components.html)’. It ‘allow us to organize parameters and targets in reusable build components, and freely compose our build out of them’.

In a nutshell, your `Build` class can ‘inherit’ from multiple interfaces, where each interface represents a ‘component’, which can have its own targets and parameters. Each interface is ultimately derived from a well-known interface (`INukeBuild`). NUKE understands this mechanism of defining targets, and will find targets defined on all ‘inherited’ interfaces.

Our earlier example with acceptance tests can now look like this:

```csharp
interface IDefaultBuild: INukeBuild
{
  Target Publish => _ => _.Executes(() => /* publish code goes here */);
}

interface IBuildWithAcceptanceTests: INukeBuild
{
  Target RunAcceptanceTests => _ => _.Executes(() => /* code to run acceptance tests goes here */);
}

class Build: NukeBuild, IDefaultBuild, IBuildWithAcceptanceTests
{
  public static int Main() => Execute<Build>();
}
```

By just implementing the `IBuildWithAcceptanceTests` interface, the build gets a whole new set of features, whereas if you choose to not implement it, the features are not in your way.

But it gets better. In our pipeline, we run the acceptance tests as part of the `Release` target &mdash; first we release the application into an environment, and then we run acceptance tests. How do we combine this with the fact that acceptance tests are optional? 

We can’t use `Triggers` on the `Release` target, because that would fail if the acceptance test component hasn’t been implemented. We _could_ use `TriggeredBy` from the acceptance test target, but that will fail if the release component hasn’t been implemented. We don’t want to _force_ people to implement particular components; they’re there if they are useful to you, and nothing more.

Instead, we can use `TryTriggeredBy<T>`. This lets you express ‘if the build is a `T`, this target is triggered by these targets’. This is just what we need. There are similar methods for `DependsOn`, `DependentOn`, `Triggers`, and even `After` and `Before`.

```csharp
interface IDefaultBuild: INukeBuild
{
  Target Release => _ => _.Executes(() => /* omitted for brevity */);
}

interface IBuildWithAcceptanceTests: INukeBuild
{
  Target RunAcceptanceTests =>
    _ => _.TryTriggeredBy<IDefaultBuild>(b => b.Release)
          .Executes(() => /* omitted for brevity */);
}
```

Now, if your build implements `IDefaultBuild` _and_ `IBuildWithAcceptanceTests`, the `RunAcceptanceTests` will automatically be triggered by the `Release` target. I call that pretty sweet.

Combining all of this with the excellent value-binding mechanism and all the other benefits provided by NUKE has made me switch to NUKE for good.

[^1]: Unless you install [Cake.Bakery](https://github.com/cake-build/bakery), and how you should do that depends on how you’re running your Cake script. Even then, it’s fairly limited.