This makes all vulkan drivers abort on DEVICE_LOST, which is better than
the current error in deqp-runner because deqp has added a new DeviceLost
test status but deqp-runner doesn't understand it yet (the next release
will though), breaking jobs when this happens.
Disable it on zink for now, as EGL test intentionally cause this in some
tests and we don't want them to start crashing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28320>
A few lines above, we disable pipelines for farm disables, but we were
missing a condition to run the container & build jobs when re-enabling
a farm, leading to invalid pipelines where test jobs for that farm are
created but the container & build jobs are missing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26809>
Use the CustomLogger class and CLI tool to create strutured logs
for poe scripts which are used by broadcom and nouveau jobs.
Renamed stage lint to code-validation and added python-test job
which runs the tests for structured and customer logger to ci.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25179>
All these jobs are redundant and a waste of resources:
- the containers have already been built & pushed in the merge pipeline
- the mesa build variants have already all passed
- the driver tests have already all passed
None of these jobs are doing anything useful in this pipeline, but it
costs a factor of 2x to our infrastructure, so let's remove them.
In other words, the only job left in the post-merge pipeline is the
`pages` job that deploys the update to the website.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26451>
We need update kernel often. We need test kernel changes often.
Introduced `KERNEL_EXTERNAL_TAG` to differ between `KERNEL_TAG` which is
also used to rebuild the containers. We don't need rebuild containers
for the external kernel, so this way we don't have to.
Updating kernel goes wruuuuuum.
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23563>
This reverts commit fac60c140b.
Turns out there are pipelines that do not create any other jobs, and
Marge requires a pipeline to pass, which means a pipeline needs to
exist, which means a job needs to always exist.
There is no reason `sanity` would be the one, but it's there so let's
just use it instead of making another one.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26080>
These are not real rules, they are just strings that have an anchor that
can be referenced elsewhere in this file.
Having these fake bits in here is confusing, as revealed by the
reactions from the first version of this commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25920>
Turns out I was right the first time, I was just missing that this
should only be done in MRs, which @daniels added in 16527f6ffd.
Without this, a "farm re-enable" pipeline will run all the jobs for that
farm, but will have none of the container & build jobs to support these
tests.
This reverts commit 1c3097225a.
Fixes: 1c3097225a ("ci: don't run everything just because a farm gets re-enabled")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25243>
Make sure we don't end up with manual container jobs in MR pipelines,
because they'll never start. This cleans up the container and build
rules so always 'do the right thing' on MRs (container+build if
required, nothing if not) and user branches (all manual).
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25219>
The argument for keeping this duplicate was to not affect
the ci_run_n_monitor script (which by default picked the pipeline in the
user's fork), but the script already supported specifying
a `--pipeline-url` to support that use-case, and it now automatically
picks the MR pipeline if there is no fork pipeline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25154>
When Marge rebases, it creates two pipelines, one in the author's account
due to the rebase and another one in the target account due to the merge
request event. Depending on the order they appear, Marge erroneously
check the author's pipeline, and since it doesn't have the rights to
start this pipeline, Marge fails to merge because it timed out (since the
pipeline never got run).
Fix this by disabling the author's pipeline (source of type "push") when
a merge request is open.
We only disable when the pipeline is triggered by marge to not affect
running ci_run_n_monitor.py script
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24730>
That file has become a bit of the new `.gitlab-ci.yml` with just about
everything in there, but a lot of its content doesn't need to be in the
same file anymore now that `!reference` exists.
Signed-off-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24090>
