The current --failfast implementation does not work on Windows.
This PR is an alternative to #22936, and it is based on the #22936#pullrequestreview-751153668:
An alternative would be to just not fix it. I mean who uses Windows anyway (to run the functional tests with --failfast).
At least with the error message, it well be clear that something went wrong. With this patch it will leave them dangling.
The current `--failfast` implementation does not work on Windows.
Again, it would be preferable to not fixing anything here. Am I missing something?
With this patch we will waste CI cycles after hitting a failure.
To quote myself:
An alternative would be to just not fix it. I mean who uses Windows anyway (to run the functional tests with --failfast).
With this patch we will waste CI cycles after hitting a failure.
A failure in functional tests is rare.
OTOH, seeing all of the failed tests can give us a useful hint for debugging (was thinking about that while reviewing and testing #23300).
For reasons mentioned above, I'd disable --fail-fast in all CI tasks.
Yeah, it is a trade-off. If there is a CI failure, it will be good to know the result as early as possible after opening the pull request. If there is more time, it will be good to know all tests that failed.
Ideally the ci infrastructure could be marked red during a run. Then the run would continue with the remaining tests.
it will be good to know the result as early as possible after opening the pull request.
With high probability a first failed test won't be the first in the run queue. Also it could be one of EXTENDED_SCRIPTS.
Therefore, the average amount of saved time for such an approach is less significant than it could appear.
Well that would be a reason to simply remove the option, thus revert #13105.