build: migrate from Cake to Nuke

[phmatray]

Replaces build.cake with a Nuke build under build/, matching FormCraft and PipeException — the portfolio's other two build-automation repos — so there is one build system to know instead of two. MasterCommander was the last classic Cake script.

Stacked on #197. Base branch is ci/nuget-trusted-publishing, not dev, because this rewrites the same publish.yml that #197 migrates to Trusted Publishing. Merge #197 first and this retargets to dev cleanly. Reviewing this diff alone shows only the Cake→Nuke change, which is the point.

The task graph is translated, not reimagined

Clean → Restore → Compile → Test → Pack → Validate → Publish, with Validate as the default target — exactly as Cake's Default stopped at Validate-NuGet-Package. Artifacts stay in ./.artifacts so nothing outside the build has to move. --rebuild still gates Clean and no-incremental, as WithCriteria(HasArgument("rebuild")) did.

TreatWarningsAsErrors is passed as an MSBuild property, not added to the project files: that binds CI and command-line builds while leaving an IDE build alone — the same reach TreatAllWarningsAs(Error) had. Putting it in the .csproj would have quietly changed local development too.

Three deliberate differences, each an improvement rather than a port

Cake did	Nuke does	Why
dotnet tool update … --global before validating	restores the local tool already pinned in dotnet-tools.json	the repo had pinned 1.0.59 and then overrode it with whatever was latest on the machine
WithCriteria(IsRunningOnGitHubActions) on publish	Requires(() => NuGetApiKey)	the criteria skipped silently off CI; a local publish reported success while pushing nothing
validated whatever globbed	asserts ≥1 .nupkg first	an empty artifacts directory used to pass as "all packages valid"

What I could not verify locally, stated plainly

global.json pins SDK 10.0.302; this machine has 10.0.301, and rollForward does not roll backward — so I could not build or run anything in this repo. I compiled build/Build.cs in an isolated directory outside the repo instead, where the pin does not apply: build succeeded, which validates every Nuke API call in it. What that does not prove is the pipeline end to end. This PR's own CI run is the first real execution of the new build, and it is what should be trusted over my say-so.

For the same reason .nuke/build.schema.json is not committed (PipeException does commit its own): Nuke writes it on first run, and I could not produce one. It regenerates on the first local ./build.sh and only affects editor completion in parameters.json.

One thing to be aware of

Nuke.Common 10.1.0 drags in transitive packages with 16 NuGet security advisories (GHSA-*). PipeException's build project reports the identical 16, so this is inherent to Nuke rather than something introduced here, and build/_build.csproj is not part of MasterCommander.sln so it never reaches the shipped package. Flagging it rather than leaving you to find it.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}