During the development of this fix, I utilized the `test_full_yaml_log`
test, which is marked as slow. This test is excellent for reproducing
past job submissions. It can be executed using the following commands:
```
lavacli jobs logs --raw 12496073 > /tmp/log.yaml
pytest .gitlab-ci/tests/test_lava_job_submitter.py -m slow -s
```
Here, `12496073` is the LAVA job ID from this specific job:
https://gitlab.freedesktop.org/mesa/mesa/-/jobs/53546660
The logs were not functioning as expected due to a few mistakes I made
with generators, such as:
- Not reusing the `time_traveller_gen` generator to call `next` more
than once.
- Forgetting to parse the YAML inside `time_travel_from_log_chunk`.
Additionally:
- Added some statistics at the end of the test to aid in diagnosing
whether the test was reproduced accurately.
- Renamed some variables for clarity.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26996>
In our process of monitoring LAVA logs, we typically skip numerous
messages to enhance log clarity. We already exclude `feedback` messages
from display. These messages were just used as a heartbeat signal,
indicating that if we are receiving them, the Device Under Test (DUT) is
active.
Practically, if we continuously receive feedback messages without any
other message level (either `debug` or `target`) for several minutes,
this could be a cause for concern, as it likely indicates the device is
in a kind of livelock state.
Therefore, it is more prudent to ignore feedback messages, as they tend
to occur frequently in unstable scenarios. However, it's important to
note that any other message level will still be considered as a
heartbeat signal.
Real case where several minutes of feedback messages indicate a hang:
https://gitlab.freedesktop.org/mesa/mesa/-/jobs/53546660
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26996>
'debian/x86_64_build' job needs 'debian/x86_64_build-base' job, but 'debian/x86_64_build-base' is not in any previous stage
Fixes: f298a0e709 ("ci: make sure we evaluate the python-test rules first")
Fixes: 2c9fdaa830 ("ci: fix python-test dependency error on merge requests")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27042>
We were just detecting if a log like
[ 143.080663] r8152 2-1.3:1.0 eth0: Tx status -71
happened once before
[ 316.389695] nfs: server 192.168.201.1 not responding, still trying
But we can use a counter to be more assured that the device is
struggling to recover and we can add let this detection happen during
the boot phase.
This mimics how other freedreno devices deal with this problem, see
`cros_servo_run.py:64` for example.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27081>
If someone were to remove the libraries that are needed for these,
`default` would simply not enable these tests, and the only thing we
could notice is that test jobs would suddenly take less time to run.
Instead, let's have a check to make sure dEQP's cmake has detected
everything and enabled these platforms.
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27041>
Due to some issues with GCC and this warning in very long files, we
disabled it when compiling NIR. Unfortunately by design Meson doesn't
allow us to set flags per source file.
The warning is still enabled in clang. but it is less commonly
used during development. To avoid missing catching those warnings,
add -Werror=misleading-indentation to the GitLab CI debian-clang build.
See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25315 for
more context. This patch is a transcription of what Eric Engestrom
suggested, except only targetting C flags (since we only disable them
for C in NIR build).
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26938>
Pipeline is unable to run due to the following error:
'python-test' job needs 'debian/x86_64_build' job, but 'debian/x86_64_build' is not in any previous stage
python-test job has the following rule:
- changes:
- bin/ci/**/*
so add it as well to debian/x86_64_build
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26802>
There is no need repeatedly downloading rust and d3d when building the docker locally
Download glext.h from github
Remove src directory and .git directory once compiling finished
Split piglit and depq compiling out
Clean middle files of piglit and depq
ci/msvc: Improve fetch source of spirv_samples_source
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26736>
packaging are installed because python 3.12 need it
Install of vulkan-sdk improved so that it's can be running in non-docker environment
Now vulkan-sdk have separate script so that it can be updated without update MSVC
THe choco installed packages is almost freeze to update, so split install of vulkan sdk
out of it for avoid update it when update VULKAN_SDK_VERSION on local computer
--params="/InstallDir:C:\python3" won't take effect, drop it for not misleading
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26736>