Environment
- Consumer repository: agenda
- Pipelines package: Candoumbe.Pipelines 2.0.0
- .NET SDK: 10.0.201
- OS: Linux (dev container)
- Test runner context: Microsoft.Testing.Platform enabled in global.json and tests.props
What I expected
Running the unit-tests target should provide a deterministic unit-test signal:
- fail only when unit tests fail, or
- fail with a clear, isolated reason directly tied to test orchestration.
What happened
Running:
./build.sh unit-tests
fails in Nuke summary with:
- UnitTests failed
- AggregateException
- Process dotnet exited with code 2
- downstream test-related targets not run
At the same time:
- running
./build.sh unit-tests --skip Format can succeed
- direct unit test execution succeeds (validated examples):
- Agenda.API.UnitTests: 44/44 passed
- Agenda.Objects.UnitTests: 21/21 passed
Additionally, the same unit-tests invocation traverses non-unit-test concerns (Format, BuildFrontend), which can introduce unrelated blockers (package vulnerability audit messages, frontend budget warnings), making diagnosis difficult.
Repro steps
- Use a consumer project with:
- Candoumbe.Pipelines 2.0.0
- .NET SDK 10.0.201
- Microsoft.Testing.Platform enabled
- Run:
./build.sh unit-tests
- Observe Nuke summary failure on UnitTests with AggregateException and dotnet exit code 2.
- Compare with:
./build.sh unit-tests --skip Format
- Compare with direct test runs:
dotnet test tests/Agenda.API.UnitTests/Agenda.API.UnitTests.csproj
dotnet test tests/Agenda.Objects.UnitTests/Agenda.Objects.UnitTests.csproj
Short log snippet
Target UnitTests has thrown an exception
AggregateException: One or more errors occurred.
Process dotnet exited with code 2.
Nuke summary: UnitTests failed; downstream targets not run.
Impact
- Hard to distinguish true unit test failures from orchestration/precondition failures.
- Slower CI and local triage.
- Reduced confidence in the unit-tests target as a test-only quality gate.
Suspected root cause
Possible orchestration coupling in the unit-tests flow:
- non-unit-test stages are part of the same execution path
- when one of those stages or command wiring fails, the top-level signal appears as a generic UnitTests AggregateException, obscuring root cause.
Proposed improvements
- Provide a strict unit-tests mode that excludes unrelated concerns (format/frontend/audit) by default.
- Improve error reporting to clearly attribute failure to the exact sub-step and command.
- Distinguish in summary:
- test assertion failures
- prerequisite/pipeline failures
- process invocation failures
- Document recommended behavior with .NET 10 and Microsoft.Testing.Platform enabled.
Optional workaround
- Use:
./build.sh unit-tests --skip Format
- Validate unit test health independently with direct dotnet test commands while diagnosing orchestration issues.
Could you please confirm whether this behavior is expected in Candoumbe.Pipelines 2.0.0, and what target strategy you recommend for a strict, deterministic unit-test gate?
Environment
What I expected
Running the unit-tests target should provide a deterministic unit-test signal:
What happened
Running:
./build.sh unit-testsfails in Nuke summary with:
At the same time:
./build.sh unit-tests --skip Formatcan succeedAdditionally, the same unit-tests invocation traverses non-unit-test concerns (Format, BuildFrontend), which can introduce unrelated blockers (package vulnerability audit messages, frontend budget warnings), making diagnosis difficult.
Repro steps
./build.sh unit-tests./build.sh unit-tests --skip Formatdotnet test tests/Agenda.API.UnitTests/Agenda.API.UnitTests.csprojdotnet test tests/Agenda.Objects.UnitTests/Agenda.Objects.UnitTests.csprojShort log snippet
Impact
Suspected root cause
Possible orchestration coupling in the unit-tests flow:
Proposed improvements
Optional workaround
./build.sh unit-tests --skip FormatCould you please confirm whether this behavior is expected in Candoumbe.Pipelines 2.0.0, and what target strategy you recommend for a strict, deterministic unit-test gate?