-
Notifications
You must be signed in to change notification settings - Fork 111
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
XFAIL a check on length of results in test_gracefull_death #7126
Conversation
Still happens in some busy environments, like recently within https://app.travis-ci.com/github/datalad/datalad/jobs/586725682 of datalad#7118
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'm kinda fine with this approach. Hence the approval.
However, I see little utility in having the test executed in the first place. Nobody was able/willing to figure it out while it was making CI fail, I predict nobody will care about an XFAIL either. So, whatever the outcome of the test - there will be no consequences. IMHO it's just wasted runtime.
from my observation - busy system. And that was at large reason for majority of other fails in test_parallel -- consumer threads are not executed in the number/order expected by the test.
In general (not this particular xfail assert for which takes virtually no time) I agree to disagree: the test has other conditions and possibly even contributes uniquely to code coverage. As with any test, "they are useless" after possibly initial TDD is done and until some changes in environment or code make them resurface problems again. But I do agree that XFAILs are largely forgotten about, as well as our Ok, overall, with this blessing let's proceed |
PR released in |
Still happens in some busy environments, like recently within https://app.travis-ci.com/github/datalad/datalad/jobs/586725682 of #7118
Attn @bpoldrack who was after all the flaky tests