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
|
@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 |
0bb7fee to
16e581a
Compare
|
@swift-ci please test |
|
I'll take a closer look on Monday! |
|
@swift-ci please test |
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
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 |
I agree we should do this; the eventual intent is for this new console output experience to be emitted from a separate ("harness") process so this will help ensure this code is able to make that transition seamlessly. That said, the scope of this PR is fairly narrow; it's focused on setting up the "skeleton" of a new console output recorder type, without any real logic of its own yet. I think in the interest of continuing progress we can land this and make the switch to using ABI/JSON types in one of the upcoming anticipated PRs. |
stmontgomery
left a comment
There was a problem hiding this comment.
Thanks for iterating on this, @tienquocbui! Congrats on the first PR landed towards this effort. We'll continue and address any remaining feedback items in upcoming PRs.
|
Thank you so much, @stmontgomery and @grynspan, for all the detailed feedback and guidance on this first PR. I'm excited to have this foundational piece merged! As we discussed, the next major step will be to refactor this reporter to consume the ABI/JSON event stream, which will be addressed in a follow-up pull request. Looking forward to continuing the work. |
…ize relevant content (#1287) This PR formally defines an "experimental" event stream version (named `ABI.ExperimentalVersion`) which represents content that is considered experimental. It then adopts the new experimental version in several places to conditionalize the inclusion of fields on event stream models which are not yet officially included in any defined, supported version. Finally, it uses this new version everywhere that intentionally always uses the _highest experimental_ version, such as the exit test back channel and the [recently-added](#1253) experimental console output recorder. ### Motivation: The event stream now has an established versioning system (as of #956) and can easily conditionalize content based on version. As a general rule, we prefer to exclude content which has not gone through Swift Evolution review when delivering data to event stream consumers which expect to receive content from a supported version. The fields this PR conditionalizes have underscore prefixes and have code-level documentation indicating their unofficial-ness, but the fact that they are included at all in supported/non-experimental version streams could lead to misuse or unintentional breakages in the future if the names or semantics of these fields change. ### Checklist: - [x] Code and documentation should follow the style of the [Style Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md). - [x] If public symbols are renamed or modified, DocC references should be updated.
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: