-
Notifications
You must be signed in to change notification settings - Fork 41
Continue running the stress tester after an error is encountered #146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Let’s see what kind of results we get out of this. Taking too long to run locally… @swift-ci Please test |
2fac180
to
7477138
Compare
7ce71f3
to
b819dc4
Compare
`SourceKitDocument` should have reference semantics, because if we pass it around, we want all instances to refer to the same object.
…if suppress output is `false`
0d20196
to
220e520
Compare
d916129
to
2c9ac71
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some small cleanups, but otherwise LGTM (as much as crash recovery can look good 😆)
let (actions, priorActions) = computeActions(from: tree) | ||
|
||
var errors: [Error] = [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't really matter, but I'd prefer the ones outside the loop to just return [error] and then only use this for the loop. Or use errors
in the last do/catch as well.
// We can control whether to stop scheduling new operations here. As long | ||
// as we return `true`, the stress tester continues to schedule new | ||
// test operations. To stop at the first failure, return | ||
// `operation.status.isPassed`. | ||
return true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could change FailFastOperationQueue
to something like OperationQueue(failFast:)
. Just seems kind of weird to use a "failing fast" queue and then not fail fast 😆.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed it to StressTesterOperationQueue
but left the API the same.
|
||
private var state: State = .running { | ||
didSet { | ||
if #available(macOS 10.12, *) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still needed (since it is set in the package)?
if isNull { return false } | ||
guard let notification = value.getOptional(.key_Notification)?.getUID() | ||
else { return false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could factor this out into notificationType
but there's only two, so not too bad right now.
The stress tester runs stable enough on the test suite now that a failure isn’t likely to cause a whole bunch of following failures. Instead, continue running after a failures is encountered to get a more complete picture of the SourceKit issues in the source compatibility suite. The current behaviour of uncovering new issues after XFailed issues are fixed is annoying.
2c9ac71
to
aa7bb02
Compare
4365f15
to
de7fd46
Compare
We are no longer using this queue to fail fast, so the name seems misleading.
Shutdown an re-initialize would (sometimes?) give us back the previous XPC connection. The crash request is working even if SourceKit is busy fulfilling other requests and is guaranteed to spawn a new process.
de7fd46
to
3d6a913
Compare
@swift-ci Please test |
The stress tester runs stable enough on the test suite now that a failure isn’t likely to cause a whole bunch of following failures.
Instead, continue running after a failures is encountered to get a more complete picture of the SourceKit issues in the source compatibility suite. The current behaviour of uncovering new issues after XFailed issues are fixed is annoying.