Implement CommandLogging-based output suppression for ModularPipelines DotNet operations

[Copilot]

This PR reduces excessive pipeline output by implementing ModularPipelines' native CommandLogging enum for DotNet operations, replacing the previous custom CliWrap extension approach based on feedback.

Problem

The TUnit pipeline was generating excessive output due to ModularPipelines streaming command output to console:

• Build operations: 6,643 lines of output
• Pack operations: 235 lines per project
• Test runs: Thousands of lines of build/execution details
• Total pipeline output often exceeded 24,000+ lines, making CI logs slow to load and difficult to navigate

Solution

Following feedback to use ModularPipelines' built-in logging controls instead of custom CliWrap extensions, I implemented CommandLogging enum configuration across all DotNet operations:

CommandLogging Configuration

// Before: Default logging streams all output
await context.DotNet().Run(new DotNetRunOptions {...}, cancellationToken);

// After: Selective logging suppresses verbose output while preserving errors
await context.DotNet().Run(new DotNetRunOptions 
{
    // ... other options
    CommandLogging = CommandLogging.Input | CommandLogging.Error | CommandLogging.Duration | CommandLogging.ExitCode
}, cancellationToken);

Comprehensive Coverage

Updated 17 pipeline modules to use CommandLogging configuration:

• TestBaseModule: Centralized configuration for all inherited test modules
• Individual modules: Direct CommandLogging configuration for Run, Test, Pack, Publish, New, and NuGet operations
• Selective suppression: Removes CommandLogging.Output flag to suppress verbose stdout while preserving error streams

Technical Implementation

The CommandLogging enum supports flags and provides granular control:

• Input (1): Log command input
• Output (2): Log command output (excluded to reduce verbosity)
• Error (4): Log error output (preserved for debugging)
• Duration (8): Log execution time (preserved for performance monitoring)
• ExitCode (16): Log exit codes (preserved for failure detection)

Configuration Input | Error | Duration | ExitCode provides optimal balance of reduced output while maintaining diagnostic capabilities.

Key Benefits

✅ Native ModularPipelines Integration: Uses built-in logging controls instead of custom CliWrap interception
✅ Comprehensive Coverage: All 17 pipeline modules configured with appropriate CommandLogging
✅ Preserved Error Visibility: Failed operations still display full diagnostic output via Error flag
✅ Minimal Code Impact: Single property addition per DotNet operation + using statements
✅ Performance Optimized: Leverages ModularPipelines' internal output control mechanisms

This approach provides the requested output reduction while maintaining full error visibility and following ModularPipelines' recommended patterns for logging control.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[thomhurst]

@copilot this is the wrong approach. Instead you should look for new processes created by CliWrap. If they complete successfully, don't stream their output to the console.

[Copilot]

@copilot this is the wrong approach. Instead you should look for new processes created by CliWrap. If they complete successfully, don't stream their output to the console.

I've reverted the verbosity flags and implemented CliWrap output suppression for successful operations. I found and fixed GlobalHooks.cs which was streaming build output to console (commit 16c9ae3).

However, I'm having difficulty locating the specific CliWrap processes you're referring to that are causing the main pipeline verbosity (6,643+ lines). Most CliWrap usage I found either uses ExecuteBufferedAsync() or redirects output to streams.

Could you point me to the specific files or processes where you'd like me to implement the CliWrap output suppression? The main sources of verbose output seem to be coming from ModularPipelines' internal command execution rather than direct CliWrap usage in the codebase.

[thomhurst]

@copilot Look for things like: context.DotNet().Run(new ...

[Copilot]

@copilot Look for things like: context.DotNet().Run(new ...

I've implemented CliWrap output suppression for all context.DotNet().Run(new ...) patterns found in the pipeline modules. Created custom QuietDotNetExtensions that use CliWrap's ExecuteBufferedAsync instead of the streaming execution, showing output only on failure. Updated 11 modules covering Run, Test, Pack, New, and NuGet operations (commit 83d37ec).

[thomhurst]

@copilot undo those extensions.

You can control the logging by using the CommandLogging enum on command options objects. It supports flags too so you can combine values.