ci/iris: Demote APL deqp to manual-only for now.
authorEmma Anholt <emma@anholt.net>
Thu, 5 May 2022 16:40:37 +0000 (09:40 -0700)
committerMarge Bot <emma+marge@anholt.net>
Thu, 5 May 2022 18:20:12 +0000 (18:20 +0000)
commit3c0e4be89bd43c4ffa970f86b14765c5f518aa13
tree0193fc7fc9e1b772235eaf70e43ac76690adca70
parent17c98393f9f3cb0801b73b2d4c62442859417368
ci/iris: Demote APL deqp to manual-only for now.

it's been flaking with "2022-05-05 16:29:49.055151: [0m[31mERROR - Failure
getting run results: parsing results: Reading from dEQP: timed out waiting
for fd to be ready (See \"//results/c32.r1.log\")" and a pile of missings
since the brief "whoops, HW CI failed to listen to the test exit code"
regression.

The only ways I know of to hit this case would be:

1) The deqp binary abruptly wedges on its own.  This happens with NFS
failures sometimes, but the rest of the run went fine and we never got the
kernel complaining about NFS, so that seems unlikely.

2) The stderr pipe filled up before stdout was completed, and deqp got
wedged trying to output stderr (happens sometimes when you do like
NIR_DEBUG=print in your run).

Both of these seem unlikely, given that we've got a big .qpa file that
made it all the way to writing out test case durations at the end of the
run before abruptly terminating.  Why didn't we have at least some of the
test results parsed?

The next deqp-runner release we integrate will solve #2, and cleans up
these error paths a bunch, so I'm hoping we get more information soon.

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16350>
src/intel/ci/gitlab-ci.yml