actions: Use pytest-rerunfailures for pytest-xdist worker crash

[zmedico]

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

[thesamesam]

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?)

[zmedico]

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...

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 looked at what the actual crash is - do you have any ideas for it yet? (Are we to blame?)

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 --only-rerun 'worker .* crashed while running' bit makes the workaround not so bad, since rerun is only triggered when absolutely necessary.

[thesamesam]

AH, thank you, sorry, I thought it was an interaction between one of our setup fixtures and multiprocessing, just exposed by pytest-xdist.