filter out ExitSuccess

This avoids displaying the unexpected exit codes message when
the list is eg [ExitSuccess, ExitFailure 1].

Sponsored-by: Dartmouth College's Datalad project
This commit is contained in:
Joey Hess 2022-05-02 14:09:37 -04:00
parent 642703c7e4
commit 217798f3f1
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 26 additions and 2 deletions

View file

@ -744,8 +744,8 @@ parallelTestRunner' numjobs opts mkts
exitcodes <- forConcurrently [1..numjobs] $ \_ ->
worker [] nvar runone
unless (keepFailuresOption opts) finalCleanup
case nub (concat exitcodes) of
[ExitSuccess] -> exitSuccess
case nub (filter (/= ExitSuccess) (concat exitcodes)) of
[] -> exitSuccess
[ExitFailure 1] -> do
putStrLn " (Failures above could be due to a bug in git-annex, or an incompatibility"
putStrLn " with utilities, such as git, installed on this system.)"

View file

@ -34,3 +34,5 @@ cron-20220418/build-ubuntu.yaml-665-0346631d-failed/test-annex (nfs-home, ubuntu
[[!meta author=yoh]]
[[!tag projects/datalad]]
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2022-05-02T17:57:21Z"
content="""
Noticed this:
Test subprocesses exited with unexpected exit codes: [ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitFailure 1,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess]
In this test run: <https://github.com/datalad/git-annex/runs/6251550145?check_suite_focus=true>
There was a test failure indeed there, which was another bug that
is now fixed. But notice the `ExitFailure 1` in the list of exit codes.
The code around handing exit codes has changed from before, and still had a bug,
because a list with `ExitFailure 1` will cause that message, incorrectly.
(Now fixed that.)
But, this seems to show that it's no longer hiding the actual problem
exit code when a test fails, which it was somehow apparently doing before.
So I think this bug can be closed as fully fixed now.
"""]]