-
Notifications
You must be signed in to change notification settings - Fork 78
[WIP] New multi-node infrastructure for integration tests #1055
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
[WIP] New multi-node infrastructure for integration tests #1055
Conversation
|
Added CI pipeline to run integration tests. @swift-server-bot test this please |
0b0645f to
afdd865
Compare
…ncl receptionist)
3d8a323 to
ed1d648
Compare
1407dfc to
55fab7c
Compare
8ad5312 to
e47c16c
Compare
|
Uncovering bugs in receptionist rewrite where ordering wasn't quite right anymore resulting in test hangs (and bad receptionist ordering bugs in the op-log). Mostly stable locally but still stabilizing tests while here... |
| extension OrderedSet { | ||
| // FIXME(collections): implemented for real in https://github.com/apple/swift-collections/pull/159 | ||
| @inlinable | ||
| internal func _filter( |
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.
missing operation in OrderedSet; upstreaming better impl: apple/swift-collections#159
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 think the uncheckedUniqueElements initializer would generally give better performance here:
let members = self.filter(isIncluded)
return OrderedSet(uncheckedUniqueElements: members)This prevents multiple rehashings of the result while it is being constructed. Copying the contents twice would still be slower than what the package can do, but reducing hash operations would still be a considerable boost!
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.
Nice, thanks for the hint!
65f9497 to
7f7b3a4
Compare
7f7b3a4 to
d872d20
Compare
0de5560 to
4645dfe
Compare
This replaces our previous "bunch of shell scripts" integration tests.
Resolves #900
I actually found a bug while doing this so will solve #1054 while doing this.
Ignore the ad-hoc JSON Coders here, those were to debug the issue.
This introduces a new way to write multi node tests which can span actual processes and automatically join a cluster.
We can aggressively KILL those processes and assert on the outputs of such clusters.
We will also easily be able to deploy tests written using this infra to multiple actual physical nodes or docker containers -- similar to how Akka's multi-jvm tests were doing way back then. This will allow us to verify on real networks etc.
It also is amazing for reproducers -- we can exactly replicate behavior, without having to do the weird "make sure we resolve as remote" and other dances.
Screenshot just FYI how an output looks like -- speaking for myself, I can't get complicated things solved without such reliable test infra, so I'm more than happy it is back!
Running tests is done via
swift package --disable-sandbox multi-node -c debug test(or justswift package --disable-sandbox multi-node testto run in-c releasemode). The plugin automatically compiles and runs tests in individual processes.This is how an example test-case looks like: