-
-
Notifications
You must be signed in to change notification settings - Fork 63
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
Scale back LSP tests #944
Scale back LSP tests #944
Conversation
2336607
to
bde16fb
Compare
OK, this PR has changed the tests so that the random number generator's state is different, and now it is blocked by test failures that cannot be reproduced locally. PyLint EDIT. Problem "fixed" by waiting for months and then rebasing. Probably this is one of the worst ways to fix a persistent problem in our tests, but it seems to be working... |
Since those tests were written, this functionality has been used in the runtime tests. If it breaks, the runtime tests will fail.
This failure cannot be reproduced locally, even with the same PyLint version and the same random seed.
This is a response to failures on remote that could not be reproduced locally. It is unclear what causes it, but if it is nondeterminism in order of test execution, then the previous way of fixing the seed was no good. With this approach, the seed will be different for every test run, but at least the seed will be reported so that failures can be debugged.
ec582f3
to
a2bd658
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.
Looks good, but did you mean to touch reactor-c
as part of this PR?
Definitely not -- I missed that while I was rebasing. |
This scales back LSP tests because they have been taking a little more computational resources on GitHub Actions than is ideal. Additionally, the "build and run" tests are now redundant.