perf: eliminate redundant builds in CI pipeline

[thomhurst]

Summary

• Add --no-build to all AOT publish steps in YAML — managed code is already built by the Build step, so only native ILC compilation runs
• Add --no-build to dotnet pack in PackTUnitFilesModule — avoids rebuilding all 15 packable projects during pack
• Add --no-build to the execute-pipeline action — TUnit.Pipeline is already built as part of the solution
• Move mock tests AOT publish from pipeline module to YAML (runs before the pipeline, 3 frameworks in parallel)
• Rename PublishAndRunMockTestsAOTModule → RunMockTestsAOTModule (only runs pre-published binaries now)

Test plan

• Verify CI pipeline passes on all 3 OS matrix legs
• Verify mock tests AOT publish + run succeeds on Ubuntu
• Verify NuGet pack produces valid packages (no-build)
• Verify TestProject AOT publish still works with --no-build

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	0

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[claude]

Code Review

This is a well-focused performance improvement to the CI pipeline. The changes are logically sound and the PR description maps clearly to each diff hunk. Here are my findings:

---

What works well

• The --no-build additions to dotnet publish / dotnet pack / dotnet run are correct given that the preceding Build step already compiles the solution. This avoids redundant MSBuild invocations and is a legitimate speed-up.
• Renaming PublishAndRunMockTestsAOTModule → RunMockTestsAOTModule accurately reflects the reduced responsibility of the class (it only runs, no longer publishes).
• Deleting the C# publish logic in favour of a YAML for loop with background jobs (& / wait) is a net simplification — the publish step has no pipeline-module dependencies, so there's no value in keeping it inside the ModularPipelines graph.

---

Concerns

1. Silent failure in the parallel publish loop

- name: Publish Mock Tests AOT
  if: matrix.os == 'ubuntu-latest'
  shell: bash
  run: |
    for fw in net8.0 net9.0 net10.0; do
      dotnet publish TUnit.Mocks.Tests/TUnit.Mocks.Tests.csproj -c Release --no-build \
        --use-current-runtime -p:Aot=true -o "MOCKTESTS_AOT_${fw}" --framework "${fw}" &
    done
    wait

wait with no arguments waits for all background jobs but returns exit code 0 even if any of the child processes failed on Bash versions prior to 4.1 (and certain edge cases on newer versions). The standard pattern to propagate failures is:

pids=()
for fw in net8.0 net9.0 net10.0; do
  dotnet publish ... --framework "${fw}" &
  pids+=($!)
done
fail=0
for pid in "${pids[@]}"; do
  wait "$pid" || fail=1
done
exit $fail

Or, simpler: set set -e (already implicit in GitHub Actions bash shell with set -eo pipefail) and use wait -n (Bash 4.3+) or capture exit codes manually. Without this fix, an AOT publish failure for one framework will not fail the CI step, yet the subsequent RunMockTestsAOTModule will try to run a non-existent binary and produce a confusing error at a later stage.

2. RunMockTestsAOTModule runs frameworks sequentially

The old PublishAndRunMockTestsAOTModule also ran frameworks sequentially, so this isn't a regression, but it's worth flagging now that the publish step has been parallelised. The three SubModule calls are awaited one at a time inside a foreach. Since each framework's binary is independent, these could run in parallel using Task.WhenAll to keep them consistent with the parallelised publish step:

var tasks = new[] { "net8.0", "net9.0", "net10.0" }.Select(framework =>
    context.SubModule<CommandResult>($"Run-AOT-{framework}", () =>
        context.Shell.Bash.Command(
            new BashCommandOptions($"DISABLE_GITHUB_REPORTER=true \"{Path.Combine(rootDir, $"MOCKTESTS_AOT_{framework}", "TUnit.Mocks.Tests")}\""),
            cancellationToken)));

var results = await Task.WhenAll(tasks);
return results;

This is a suggestion rather than a blocker — sequential execution is safe and may be preferred for log readability.

3. Hard-coded executable name assumes Linux

var exePath = Path.Combine(rootDir, $"MOCKTESTS_AOT_{framework}", "TUnit.Mocks.Tests");

The ModuleConfiguration skips execution on non-Linux platforms, so the Linux-only name is never wrong in practice. However, the Configure() guard is now the only thing preventing a crash on Windows (no .exe extension). The old code explicitly chose the filename based on RuntimeInformation.IsOSPlatform(OSPlatform.Windows), which was self-documenting. A brief comment explaining the assumption would help future readers:

// Guard in Configure() ensures this only runs on Linux, so no .exe suffix needed.
var exePath = Path.Combine(rootDir, $"MOCKTESTS_AOT_{framework}", "TUnit.Mocks.Tests");

4. --no-build on TUnit.TestProject AOT publish spans a version property mismatch risk

dotnet publish TUnit.TestProject/TUnit.TestProject.csproj -c Release --no-build ...
  "-p:Version=${{ steps.gitversion.outputs.semVer }}"
  ...

With --no-build, the version properties passed here are not baked into the already-built assembly — the assembly was compiled in the Build step without those -p: overrides (the Build step does pass the same version flags, so this is fine). Just confirming: since the Build step already stamps the version into the binary, passing them again to dotnet publish --no-build is harmless but redundant. This isn't a bug, but it's worth noting for future cleanup.

---

Summary

The overall approach is correct and the changes are a meaningful improvement. The one item worth fixing before merge is concern #1 (silent failure on parallel publish). The rest are suggestions.

[claude]

Follow-up review (after latest commits)

The third commit (d0385124) removes --no-build from the AOT publish steps, correctly recognising that --use-current-runtime requires a RID-specific build that the general solution Build step does not produce. That is the right fix and addresses the concern about publish correctness.

One open issue: wait still does not propagate child failures

The parallel publish loop in dotnet.yml still has the same pattern:

- name: Publish Mock Tests AOT
  if: matrix.os == 'ubuntu-latest'
  shell: bash
  run: |
    for fw in net8.0 net9.0 net10.0; do
      dotnet publish TUnit.Mocks.Tests/TUnit.Mocks.Tests.csproj -c Release \
        --use-current-runtime -p:Aot=true -o "MOCKTESTS_AOT_${fw}" --framework "${fw}" &
    done
    wait

GitHub Actions sets set -eo pipefail on bash shells, but that flag only applies to the foreground shell. Background jobs (&) run in a subshell where the pipefail flag is not inherited, and wait (with no PID argument) returns exit code 0 regardless of what the background jobs returned, on Bash versions before the fix in Bash 5.1+ (and even on newer versions this is environment-dependent). In practice this means a failed AOT publish for one framework silently passes this step, and the failure surfaces later as a confusing "binary not found" error in RunMockTestsAOTModule.

The safe, portable fix is to capture PIDs and wait on them individually:

run: |
  pids=()
  for fw in net8.0 net9.0 net10.0; do
    dotnet publish TUnit.Mocks.Tests/TUnit.Mocks.Tests.csproj -c Release \
      --use-current-runtime -p:Aot=true -o "MOCKTESTS_AOT_${fw}" --framework "${fw}" &
    pids+=($!)
  done
  exit_code=0
  for pid in "${pids[@]}"; do
    wait "$pid" || exit_code=$?
  done
  exit $exit_code

wait <pid> returns the exit code of that specific background process, making failure detection reliable across all Bash versions present in GitHub-hosted runners.

Everything else looks good

• NoBuild = true on dotnet pack in PackTUnitFilesModule is correct — the solution is already built before packing.
• --no-build on dotnet run in execute-pipeline/action.yml is correct — TUnit.Pipeline is compiled as part of the solution build.
• The rename from PublishAndRunMockTestsAOTModule to RunMockTestsAOTModule is accurate and clean.
• The [DependsOn<RunMockTestsModule>] dependency is preserved, keeping ordering correct.