cake-build/cake: three runners, one C# DSL, and a repository that builds itself

What this project actually is

Cake, which the repository describes as C# Make, is a build automation system with a C# domain specific language for the work a build script usually does. The README names the categories directly: compiling code, copying files and folders, running unit tests, compressing files, and building NuGet packages. That list is the project's scope in full, and it is worth noting what is absent, because there is no plugin marketplace framing, no implicit task discovery, and no requirement that your build live in a particular language's ecosystem. A Cake script is a C# file, so anything you can express in C# is available to a build script, including your own helper methods and types.

The repository is the tool itself, not a wrapper around something else. It is C#, MIT licensed, at 4,190 stars with 779 forks and 224 open issues, and the description on the repository is the plain version: a cross platform build automation system. The default branch is `develop`, which is the branch to watch if you want to know what is coming. The last push recorded in the project metadata is 2026-09-23, so this is an actively maintained codebase rather than an archived one.

Three runners, and the choice is about where the build lives

The most consequential design decision in the project is that it ships three runners rather than one, and the README's table makes the distinction legible by listing each runner against both a released NuGet package and a develop feed.

Cake.Tool is the .NET tool runner. You install it as a global tool and invoke it with `dotnet cake`, and it discovers and runs the script in your working directory. This is the lowest friction entry point and the one most people meet first.

Cake.Frosting is the compiled runner. Instead of handing Cake a script to interpret, you write a C# program that references the Cake API and references your addins, so your build is a real assembly with real types. When your build logic grows past a script, this is the shape that stops fighting you, because the build stops being text that gets bound at runtime.

Cake.Sdk is the MSBuild-integrated runner. It brings Cake into the SDK-style project world so the build sits alongside the project it builds rather than beside it.

All three publish to NuGet for released versions and to an Azure Artifacts feed for `develop`, so the table in the README is also the mechanism for opting into pre-release Cake. That pairing matters for anyone who wants to see addin compatibility against unreleased Cake, since the develop feed is where those combinations get exercised first.

The repository builds itself with Cake

The root of the tree is where the dogfooding becomes visible. There is a `build.cake`, a `build.ps1` and a `build.sh`, and the two shell entry points exist so the same Cake script can be launched from PowerShell on Windows and from a shell elsewhere. `global.json` pins the SDK version the build expects, and `GitVersion.yml` drives version calculation. A `nuspec/` directory sits alongside them, which is how the three NuGet packages in the runner table get their metadata.

Below that, `src/` and `tests/` are the obvious split for a C# project of this size, and `.editorconfig` alongside them is a reasonable signal about how the maintainers treat consistency. The `.rwx/` directory is less common and is what catches attention when reading the tree, since nothing in the README explains it.

The point of a `build.cake` in a build tool repository is that the project's own CI exercises the tool. Every bug entry in the release notes reads like a user report, but the fixes were validated against Cake itself first, which is a stronger position than having a test suite that only mocks the DSL.

Nine CI configurations across five providers

The continuous integration table is the widest part of the README and it is the clearest statement of what cross platform means here. Five build providers run against the same `develop` branch, and the platform list is longer than the provider list.

Azure Pipelines carries six of the configurations: Windows, macOS, Ubuntu, Debian, Fedora and CentOS. AppVeyor covers Windows. TeamCity covers Windows. Bitrise covers macOS and Debian. Bitbucket Pipelines covers Debian.

The distribution spread is the part that earns the description. Three Linux distributions from the Azure Pipelines set plus Ubuntu, and two separate providers picking up macOS, means a build script has to behave on filesystems with different case sensitivity rules and different line ending defaults. A build tool that only ran on Windows would not need any of that.

The AppVeyor and Bitrise rows carry a second set of badges for integration tests, so integration coverage is tracked separately from compilation on the two providers that support it. The dotnet based nature of the project makes Linux coverage comparatively cheap to add, which is presumably why six Linux configurations appear at all.

Release cadence and what the bug list reveals

Three releases are recorded, and the spacing between them sets the rhythm. v6.1.0 shipped on 2026-03-01, v6.2.0 on 2026-05-22, and v6.3.0 on 2026-09-14. That is roughly two to four months apart, and each entry opens with a count of issues closed: 43 for v6.1.0, 36 for v6.2.0, and 60 for v6.3.0.

The bug list is more informative than a changelog usually is, because it shows which parts of the tool people actually hit. v6.1.0 contained a breaking change, with GitLab's `CI_PIPELINE_ID` exceeding int limits on gitlab.com and the variable moving to a long (#4656, resolved in #4748), alongside fixes for console log colorization (#4662) and for `DotNetSlnList` hardcoding English output (#4667), which is the kind of fix that only matters for users outside English locales. v6.2.0 addressed execution semantics: `GetFiles()` returning empty results with curly brace globs (#2666, an issue number that predates the current maintainers by a wide margin), `SetupContext.TasksToExecute` listing only tasks for the first target (#4066), and common dependent tasks executing twice across multiple targets (#4324). v6.3.0 fixed report table rendering in terminals without a black background (#4870) and CS8632 warnings when Cake.Tool generated aliases from nullable-enabled addins (#4977), and added typed aliases for dotnet tool subcommands (#4890).

Read together, these point at a tool where the execution model is stable but the edges are being smoothed. Glob semantics, target resolution and duplicate task execution are all graph-level concerns, and having three separate fixes to graph-level behaviour in one release cycle is a normal consequence of a large addin ecosystem rather than a sign of instability.

Who maintains it, and what the topic list signals

The pull requests in the release notes are largely resolved by devlead, sometimes against issues filed by others, which is the signature of a project with a small core team and a wide contributor base. patriksvensson and augustoproiete appear as resolvers as well, and the volume of external issue reporters on items like the curly brace glob bug suggests the project has been in use for long enough to have accumulated a large body of accumulated edge cases.

The topic tags describe the ecosystem more honestly than the description string does. Beyond the obvious build automation and build tool labels, the list includes `dotnet`, `dotnetcore`, `nuget`, `hacktoberfest`, `orchestration`, `nunit`, `xunit` and `continuous-integration`. The unit testing framework tags are the interesting ones, because Cake's test aliases are what make test invocation a build step rather than a separate concern, and the fact that both NUnit and xunit are tagged says the tool spans the testing split in the .NET world rather than picking a side.

The homepage is cakebuild.net, which is where documentation and addin listings live rather than in this repository. That division is the usual one for a tool of this shape: the repository holds the engine and its own build, and the site holds the documentation and the catalogue of addins that make the DSL wide enough to cover a real build.

Editorial conclusion

The interesting thing about this repository is that it uses the thing it ships. `build.cake` at the repository root is a Cake script, and the CI matrix that runs on every push is what tests it, which is why a bug like the double execution of common dependent tasks in v6.2.0 (#4324) gets found in the project's own build before it reaches an addin author. Three runners ship side by side, Cake.Tool for developers who want a single command, Frosting for teams that want the build to be a compiled program, and Cake.Sdk for MSBuild-integrated builds, and choosing between them is a decision about where the build lives rather than about what it can do. At 4,190 stars and 224 open issues with a release roughly every four months, the open question is throughput rather than maintenance, since the maintainers appear as the resolver on most bug entries and the issue queue is where new work accumulates. If you are evaluating it, install Cake.Tool from NuGet and write a three-line script that copies a directory, because the DSL reads like C# and the first script is where the value becomes obvious.

Frequently asked questions

Official sources

1. cake-build/cake on GitHub
2. License: MIT
3. Project website
4. README
5. Releases