Include severity and isFailure for Issues in the published JSON event stream#1279
Conversation
|
@swift-ci test |
| await test.run(configuration: configuration) | ||
| } | ||
|
|
||
| let decodedRecords = try FileHandle(forReadingAtPath: temporaryFilePath).readToEnd() |
There was a problem hiding this comment.
I assume this was copied from another test; should we factor it into a helper?
There was a problem hiding this comment.
Added helpers a helper to wrap the common behaviour for reading and deserialising ABI.Record JSON from a file. Take a look and let me know what you think.
If we're looking to do more testing on the event stream longer term, it might make sense to create some sort of EventStreamFile object to make it slightly easier to work with arrays of ABI.Record. In particular, we do a lot of filtering on Record.kind which is a little awkward since it's an enum with an associated value.
I'm not doing that in this change to keep it more lightweight, but wanted to bring that up as a possible future direction.
|
@swift-ci test |
… stream ### Motivation: - Proposed and accepted in ST-0013 [^1], so we can move ahead and include this in the event stream. - This will _not_ be available in event stream version 0 as this is considered a breaking change [^2] ### Modifications: - Promote existing _severity/_isFailure fields -> severity/isFailure without the underscores This effectively makes them part of the official JSON ABI. The underscored names will no longer be accessible, but they were always experimental so this is not considered a blocker. - Only emit severity/isFailure when using event stream version >= 6.3 This removes access to the underscored names from earlier versions, but again, these were experimental. - Remove hidden __CommandLineArguments_v0 argument isWarningIssueRecordedEventEnabled This was only for internal testing use, but is obsolete because we test issue severity by specifying event stream version >= 6.3. ### 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. [^1]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/testing/0013-issue-severity-warning.md [^2]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/testing/0013-issue-severity-warning.md#integration-with-supporting-tools # Conflicts: # Sources/Testing/ABI/EntryPoints/EntryPoint.swift
0a07bd8 to
64505c3
Compare
Add support for swift-testing issue severity, added in swiftlang/swift-testing#1279 If an issue is recorded with a severity that does not meet the threshold for a failure then don't record the issue.
Add support for swift-testing issue severity, added in swiftlang/swift-testing#1279 If an issue is recorded with a severity that does not meet the threshold for a failure then don't record the issue.
Motivation:
Proposed and accepted in ST-0013 1, so we can move ahead and include this in the event stream.
This will not be available in event stream version 0 as this is considered a breaking change 2
Modifications:
Promote existing _severity/_isFailure fields -> severity/isFailure without the underscores
This effectively makes them part of the official JSON ABI. The underscored names will no longer be accessible, but they were always experimental so this is not considered a blocker.
Only emit severity/isFailure when using event stream version >= 6.3
This removes access to the underscored names from earlier versions, but again, these were experimental.
Remove hidden
__CommandLineArguments_v0argumentisWarningIssueRecordedEventEnabledThis was only for internal testing use, but is obsolete because we test issue severity by specifying event stream version >= 6.3.
Checklist:
Fixes rdar://158621033
Footnotes
https://github.com/swiftlang/swift-evolution/blob/main/proposals/testing/0013-issue-severity-warning.md ↩
https://github.com/swiftlang/swift-evolution/blob/main/proposals/testing/0013-issue-severity-warning.md#integration-with-supporting-tools ↩