They got accidentally disabled entirely, so they didn't block merge, but
once they re-enable then they'll block us again. The problem was that I
moved allow_failure to a .performance-rules section, but we only ever
inherit the rules from that location, not the rest of yml.
This is basically a revert of 67547a04b6 ("ci: Move the performance
jobs' allow_failure:true to the gl rules."), though I still keep the
allow_failure in a more common location with comments, since perf jobs are
a huge trap.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21002>
We have a common pain point with fractional CTS coverage, where the test
list changes on a CTS uprev or board load rebalancing, so you get a
different subset of tests run. The dev updates the list of xfails (a
pain), but also we end up with xfails left behind that aren't tested any
more and don't reflect reality.
For some drivers (tu, freedreno, zink-anv) we have manual jobs available
for curious devs to look at the current state of the CTS, but without
anyone having to keep the full xfails updated during uprevs, you don't
necessarily know what to do with the results you get on your MR.
So, let's introduce nightly testing for the tests that aren't guaranteed
green by Marge. With that, Someone (possibly me? sigh) can review the
nightly results and push up updates for full-run xfails so everyone can be
on the same page other than a day or so of delay. We also have some hope
for automated tooling to do this thanks to what Collabora has been working
on for automated CI uprev MR generation.
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20950>
If you're only affecting one or a couple of drivers, it would be nice if
your pipeline buttons on the web UI weren't full of manual run buttons for
all the other drivers.
This is a bunch of duplicated lines, but less than it could have been now
that we have !references.
In some of these cases (i915g, nouveau, etnaviv), we have no non-manual
jobs for those drivers, so I could have just rewritten the original
"driver-rules" to "driver-manual-rules". I decided to keep things
consistent between drivers, though, because this is all esoteric enough to
readers already without making different drivers' rules look different.
Fixes: #4891
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17445>
For now the restricted traces aren't available to the intel devs, so it
won't actually run for them, but I can manage that part for a bit until we
get the policy updated on the minio side (issue filed to do so).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20503>
This is the compiler for both Bifrost and Valhall, and presumably future
Mali GPUs too. Give it a more generic name so we can use the bifrost/ path for
something a bit more specific.
For historical reasons the compiler's name is still "bifrost" and uses the
prefix `bi_`. I think that's ok in the same way that i915 in the kernel supports
way more than just i915.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20455>
This mirrors all the other *_FARM variables, and allows developers to
quickly disable all the jobs that would otherwise run on Valve's CI
infrastructure by setting it to the 'offline' value.
To this end, .radv_rules gets split into .radv-collabora-rules and
.radv-valve-rules, since the driver will be testable in two different
test farms. Every radv job is then made to inherit from the right farm.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19556>
This is a farm of 5 (6, but one fails) TK1 boards for nouveau testing,
hosted and maintained by me. Currently it runs GLES dEQP.
I've been using ./.gitlab-ci/bin/ci_run_n_monitor.py --stress --target
gk20a to test it and am pretty confident of the skips/flakes list. Last
night it ran 318 jobs without fail, and prior to that there were two sets
of runs in the 100-200 range where only the one failing runner failed any
jobs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18497>
I mistakenly applied .gl-rules to the non-freedreno perf jobs, which
caused them to be incorrectly run pre-merge when core GL files changed.
Pull the freedreno core GL performance job rules out, explain a bit more
what is going on, and use it from iris and virgl performance testing.
This also drops running freedreno performance when core vulkan files
change -- freedreno perf testing doesn't have any turnip usage, nor does
it watch for turnip file changes.
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17386>
... and explain what they're doing, compared to the test rules in
test-source-dep.yml.
Unfortunately, we can't really pull them into test-source-dep.yml with
other source deps, because of various '&'-'*' references.
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17386>
This drops the mesa/gallium lists from some build rules, since zink common
rules brings them in already. If we do more driver common rules, we might
end up with those core lists appearing in the yaml multiple times, but
that seems like a small price to pay for not being able to forget some.
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17287>
