actions: Use pytest-rerunfailures for pytest-xdist worker crash#1273
Conversation
|
bleh. I'm not hard-against it, just worried we're papering over the problem with this. But I suppose it's better than flaky CI which may-or-may not fail for unrelated changes... I haven't looked at what the actual crash is - do you have any ideas for it yet? (Are we to blame?) |
It's a pytest-xdist problem though, since it doesn't trigger without it, and pytest-rerunfailures is designed to handle it since pytest-dev/pytest-rerunfailures#158.
I haven't been able to trigger it locally, so that makes it extra mysterious. Since using a private multiprocessing context for the spawn start method didn't help in #1270, I think we can safely say it's not our fault. It might be pytest-dev/execnet#96 since that's an "intermittent" issue. The |
4cab84d to
5c66967
Compare
|
AH, thank you, sorry, I thought it was an interaction between one of our setup fixtures and multiprocessing, just exposed by pytest-xdist. |
Since pytest-xdist workers crash intermittently for the multiprocessing spawn start method, use pytest-rerunfailures to detect and handle this case. Only use pytest-rerunfailures for the spawn start-method since that is the only case where we've observed intermittent pytest-xdist worker crashes, and use --only-rerun 'worker .* crashed while running' to ensure that rerun only triggers for worker crashes. Bug: https://bugs.gentoo.org/924416 See: pytest-dev/execnet#96 Signed-off-by: Zac Medico <zmedico@gentoo.org>
5c66967 to
ffcb1eb
Compare
Since pytest-xdist workers crash intermittently for the multiprocessing spawn start method, use pytest-rerunfailures to detect and handle this case. Only use pytest-rerunfailures for the spawn start-method since that is the only case where we've observed intermittent pytest-xdist worker crashes, and use
--only-rerun 'worker .* crashed while running'to ensure that rerun only triggers for worker crashes.Bug: https://bugs.gentoo.org/924416