Some changes unintendedly slipped into an unrelated commit before it was
merged.
This caused kernel modules to be built and installed in the ramdisk,
which caused some devices to fail to boot due to the ramdisk size limit
being surpassed.
These changes weren't in effect until a subsequent commit triggered a
rebuild of the ramdisks.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Fixes: a9560939e0 ("ci: Build-test Panfrost tools")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6167>
If another MR was merged while these were still running for the main
project, the result could be no updated images in the main project
registry (forcing a rebuild of the new images in all forked projects) or
an outdated Mesa website.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6011>
It's something that was added to ease development, but that was supposed
to be removed before merging.
It also causes problems when arm-related jobs aren't enabled, as
arm_build is needed by these jobs but in that case isn't there.
Also extend from .ci-run-policy.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5802>
Place the kernel and ramdisk into a place in the file server so the URL
will only change when the contents also change.
Also put the Mesa build into a separate tarball so the ramdisk's
contents don't change every build.
With proper caching in place, all devices in the same farm need only to
download the mesa tarball once, saving time.
As we switch to MinIO for making kernels and rootfs available to LAVA
devices, we can stop using Docker to distribute them.
Instead, build when needed in separate jobs that push directly to MinIO,
from where LAVA devices can download them.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515>
Phase two of our network reconfiguration is happening this afternoon, so
we need to drop our RK3399 out for a little while. (Part of this
reconfiguration is to shard our devices across networks and racks, so
losing one part of our infrastructure doesn't mean losing any particular
device type.)
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5689>
Switches have been rewired, VLANs have been reconfigured, network
elements with non-functional remote management have been removed from
racks and thrown on desks in anger.
This reverts commit ae6e1aee7d1bd49ae494b8a25ca33d092a3a145a.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5301>
We're reconfiguring our Cambridge office lab networking and physical
setup for more scalability amongst other things. We can still run jobs
on one RK3399 at the peak outage, but we'll lose the T7x0 this morning,
so disable it until it's all back.
T820 is still disabled due to an unrelated BayLibre internal outage.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5296>
Currently, we store the kernel and ramdisk for each LAVA job in the
artifacts of the job that built them. Because artifacts are stored in
GCE and LAVA labs aren't, this causes a lot of egress with is expensive.
To avoid this, have runners download most of the data via the (cached)
container images once, and for each job upload the kernel and ramdisk to
a server outside GCE.
Right now we only have Collabora's runner with a local web server, so
jobs that go to Baylibre's lab have been disabled.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
This supports powering up the device (using an external tool you
provide based on your particular lab), talking over serial to wait for
the fastboot prompt, and then booting a fastboot image on a target
device.
I was previously relying on LAVA for this, but that ran afoul of
corporate policies related to the AGPL. However, LAVA wasn't doing
too much for us, given that gitlab already has a job scheduler and
tagging and runners. We were spending a lot of engineering on making
the two systems match up, when we can just have gitlab do it directly.
Lightly-reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4076>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4076>
For now tests only use these drivers:
* llvmpipe
* softpipe
* freedreno
* lima
* etnaviv
* panfrost
So using rules:changes gitlab feature to run the tests when the changes
made are potentially affecting these drivers.
A few notes:
* the following code:
.piglit-test:
extends:
- .test-gl
- .llvmpipe-rules
makes gitlab replace .test-gl "rules:changes" values by the one from
".llvmpipe-rules".
* rules:changes always matches for non-MR new branches so jobs will always be
created (and they'll be run if their dependencies are run). For pushes to
existing branches the files changed by the push are used to match the
rules:changes path.
* the same gitlab feature could be used for some build jobs
Acked-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569>
Now that we have 7 (soon 8) boards available, there's capacity to be
testing GLES 3.0. However, due to (it looks like) buffer overflows in the
driver, we end up with flaky test results: 1/60 jobs spuriously failed,
and another 6/60 jobs reported flakes. At 6 jobs per pipeline, that's way
too high of a failure rate to enable for non-freedreno developers. Leave
the job present but disabled so that we can do manual test runs for
regressions.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3661>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3661>
This should get us better stability of the db410c boards by having a
smaller per-board software stack, with no disks involved (just initramfs).
Additionally, the new cluster is 7 (soon 8) db410cs, while currently the
docker cluster only has 1/4 of its db410cs still running.
Unfortunately, we have to prepare the fastboot boot image during the ARM
drivers build stage, because LAVA relies on publicly available URLs for
the images to load into the bootloaders of the boards, and the only thing
we have for that is gitlab's artifacts.
Note that this testing relies on the boards being freshly flashed with the
linaro v136 firmware to pick up the initramfs size fixes and to stop the
boot at fastboot.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3661>
