-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Stabilize CI? #8317
Stabilize CI? #8317
Conversation
Thanks for the pull request @mramato!
Reviewers, don't forget to make sure that:
|
Nope, Vector3DTileContent still failed. @lilleyse any objections to just |
@mramato fine with me until we can figure out why. I ran just
|
It fails randomly, sometimes it works, sometimes it doesn't. It is much more likely to fail on travis (possibly because of a slow machine, I don't know). But the problem is that we really need CI to only fail when there is a legitimate error or else it just slows us all down. |
This continues to be a thorn in our side, I'm going to xdescribe the spec and bump CI a bunch of times. |
Yup, fine with me. We can look into it later. |
Random Vector3DTileContent test failure seem to be the primary cause of CI problems these days: https://travis-ci.org/AnalyticalGraphicsInc/cesium/builds/602749111
These tests are a mess and do way to much work to really be considered unit tests, the larger problem is the architecture that requires loading a full tileset just to test Vector3DTileContent.
For now, I'm just trying to stabilize CI and I think moving some code into beforeEach instead of beforeAll may do it. Opening this so I can force it a bunch of times and see how it does.
I'm tempted to just ignore Vector3DTileContent specs completely if this doesn't fix it, since having constant random CI failures is really a drag on Cesium development.