Add experimental AdvancedConsoleOutputRecorder skeleton framework #1253
Conversation
…ting - Implement Event.AdvancedConsoleOutputRecorder with beautiful tree structure - Add SF symbols support with colors (play.circle, checkmark.circle, x.circle, etc.) - Right-aligned timing display with 80-column fixed width - Unicode box-drawing characters for hierarchical test output - Issues displayed as sub-nodes under failed tests - Enhanced start message with test count and running status - Thread-safe parallel execution support - Color-coded final summary with status icons - Replace basic ConsoleOutputRecorder with enhanced version - Add demo test files for validation Features: ✅ Hierarchical tree structure with proper indentation ✅ SF Symbols on macOS with Unicode fallback ✅ Right-aligned timing information ✅ Color-coded status icons and output ✅ Issues as expandable sub-nodes ✅ Enhanced start/end messages ✅ Thread-safe concurrent test execution
Implementing progress bar with live update
- Add experimental AdvancedConsoleOutputRecorder activated via environment variable - Implement clean skeleton structure for incremental PR development - Fix terminal width hardcoding with 80-char safe fallback - Follow HumanReadableOutputRecorder delegation pattern - Update style guide compliance (80-char comment wrapping) - Re-enable AttachmentTests and disable slow demo test suites - Remove Foundation dependencies and signal handling - Prepare foundation for PR #1 (Skeleton), PR #2 (Hierarchy), PR #3 (Progress)
- Update to latest main branch from upstream/main - Integrate new ABI version handling and entry point improvements - Preserve AdvancedConsoleOutputRecorder skeleton implementation - Ready for first PR submission
Complete skeleton PR #1 preparation: - Clean AdvancedConsoleOutputRecorder framework - Environment variable activation integrated - Latest upstream changes merged - Ready for first PR submission
- Use upstream conditional compilation directives - Match upstream verbosity check (> .min instead of >= 0) - Simplify AdvancedConsoleOutputRecorder options for skeleton - Fix event handler ordering to match upstream pattern - Maintain zero impact on default behavior
tienquocbui
requested review from
stmontgomery,
grynspan,
briancroom and
suzannaratcliff
as code owners
stmontgomery
added
enhancement
|
@swift-ci please test |
|
I've changed this PR to draft status for the moment. Once CI is passing, we can bring it back up. (I just don't want to accidentally click Merge before then.) |
The Environment.flag(named:) function returns Bool? but was being used directly in an if statement. Changed to explicit comparison with true to handle the optional properly.
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test Linux |
tienquocbui
force-pushed
the
gsoc-development
branch
from
0bb7fee to
16e581a
Compare
|
@swift-ci please test |
|
I'll take a closer look on Monday! |
|
@swift-ci please test |
Sources/Testing/Events/Recorder/Event.AdvancedConsoleOutputRecorder.swift
Outdated
Show resolved
Hide resolved
Sources/Testing/Events/Recorder/Event.AdvancedConsoleOutputRecorder.swift
Outdated
Show resolved
Hide resolved
Sources/Testing/Events/Recorder/Event.AdvancedConsoleOutputRecorder.swift
Outdated
Show resolved
Hide resolved
Sources/Testing/Events/Recorder/Event.AdvancedConsoleOutputRecorder.swift
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
There's an overall abstraction problem here, which is that this code is eventually going to be moved to a separate repository (either SwiftPM or a new one) and will need to decode the JSON event stream rather than directly interact with our Swift Event type and its friends.
The code you build for this feature should be structured to take JSON Lines as input so that it's easy for us to migrate it. Otherwise it creates a large amount of work for us in the future to rewrite it to do that. Let's get it right the first time!
So I'd suggest that you refactor this code so that the event handler in EntryPoint.swift generates JSON lines as output (note we already do that, so see if you can reuse the existing code path for that!) and then have AdvancedConsoleOutputRecorder decode the JSON lines and process them.
(The visible effect will be that the output does not get forwarded to the existing ConsoleOutputRecorder type, but that's okay. We're not trying to make it look pretty yet.)
I don't see this functionality, even stubbed out, anywhere. Did I miss it? |
- Change handle() to record() for consistency with other recorders - Update documentation to use proper DocC reference (Event/ConsoleOutputRecorder) - Remove unused configuration options (useHierarchicalOutput, showSuccessfulTests) - Simplify LiveUpdatingLine documentation - Remove future capability descriptions from main documentation
tienquocbui
force-pushed
the
gsoc-development
branch
from
cd25ed3 to
3c80e1b
Compare
Since we cannot control the output stream, the LiveUpdatingLine functionality is not usable in practice and should be removed from the skeleton implementation.
That's my mistake in the PR description, the terminal width detection will be implemented in the follow-up PRs |
|
@swift-ci please test |
Add experimental AdvancedConsoleOutputRecorder skeleton framework
Motivation:
The current console output for
swift testis a static log, which presents challenges for developers in understanding test progress and diagnosing failures, especially in large, parallel test suites. This PR introduces the foundational "skeleton" for a new, advanced console reporter to address these issues.The recorder is marked as experimental and must be explicitly enabled via the
SWT_ENABLE_EXPERIMENTAL_CONSOLE_OUTPUTenvironment variable, ensuring it doesn't affect existing functionality.Modifications:
Event.AdvancedConsoleOutputRecorder.swift: New experimental console output recorder skeleton with:Event.ConsoleOutputRecorderfor actual outputThe implementation provides the foundation structure following established patterns in the codebase, ready for future development of advanced console features.
Checklist: