A failed dotnet pack only logs a warning, so the release is tagged and published without that package and the run stays green #182

What's wrong

DotNetService.PackAsync packs each project on its own. When dotnet pack exits non-zero, it logs a warning and moves on to the next project (KtsuBuild/DotNet/DotNetService.cs:306-324).

ReleaseService.ExecuteReleaseAsync (KtsuBuild/Publishing/ReleaseService.cs:35-40) then continues regardless:

• It publishes whatever .nupkg files were produced.
• It creates and pushes the vX.Y.Z tag and the GitHub release.
• The ci / release command exits 0.

Concrete scenario

A repository ships Foo and Foo.Extensions. During a release run, Foo.Extensions fails to pack, for example with an NU5xxx metadata error or a missing README or icon.

1. Foo 1.3.0 is pushed to nuget.org.
2. Tag v1.3.0 and the GitHub release are created.
3. The workflow is green.
4. On the next scheduled run, v1.3.0..HEAD has no commits, so CommitAnalyzer returns Skip and nothing is released again.

Foo.Extensions 1.3.0 is never published. Consumers who update both packages together hit a version mismatch. The only trace is one warning line in a green log.

Why continuing gains nothing

A project that is legitimately not packable (ktsu.Sdk sets IsPackable=false for apps and tests) makes dotnet pack a no-op that exits 0. A non-zero exit is therefore a real failure, not a "nothing to pack" signal. Projects that don't fit the host are already filtered out by GetBuildableProjects.

Note

This behaviour is pinned by KtsuBuild.Tests/DotNet/DotNetServiceTests.cs:517 (PackAsync_PackFailure_LogsWarningButContinues, "Should NOT throw - pack failures are logged as warnings"). It looks inherited from PSBuild, and I couldn't find a documented reason for it. The fix has to change that test deliberately.

Suggested fix / acceptance criteria

• Pack every project and collect the failures. Then throw a single exception naming every project that failed, before ReleaseService publishes anything or creates the tag.
• Replace the existing test with one asserting that a failed pack throws. Add a test in ReleaseServiceTests asserting that no publish, tag or release call follows a failed pack.
• A pack that exits 0 but produces no package is still not an error.