The template already does this at the end, so this step is
pointless in the best case.
When building the x86-64 image, we install additional packages
afterwards, so the repo metadata is downloaded again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3010>
This is a followup to GNOME/mutter!1578
This commit does a couple of things to avoid creating multiple
pipelines per commit.
First, it avoid catch all `when: manual` rules, which might
end up matching custom variables set which might potentially
not be handled.
Secondly it reworks the `workflow:rules:` and the pipeline guard
rules to avoid duplicate pipelines as the gitlab documentation
suggests.
Last, it switches from yaml anchors to the new `reference` gitlab
keyword which is more flexible.
https://docs.gitlab.com/ee/ci/jobs/job_control.html#avoid-duplicate-pipelines
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2534>
The image build step is prone to race conditions, e.g. token changes. It
also tends to hit sporadic connection errors to FDO's gitlab. To
minimize the risk of these types of issues block pipelines, always retry
the image building step if it failed.
This has the unwanted consequence that changes to the image building
that results in the script actually failing, but right now there doesn't
appear to be a way to distinguish between actual build errors, and the
mentioned race conditions, as both cause the script to fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2564>
This commit makes the KVM tests run in special VM runners tagged with
the 'kvm' tag. In order to avoid building the kernel image used for
running the tests each pipeline, it's built as part of the CI image
building.
For now, KVM tests are only run on the x86_64 architecture. The reasons
for this are two that the kernel image building script doesn't yet handle
any other architecture than x86_64 due to differences in how the image
is built and handled, as well as the fact that there only exists a kvm
tagged runner for x86_64.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2152>
Instead of having different coverage outputs for different architectures
and compilation flags, have each of those tests run coverage in order
to generate a JSON report, and have that merged at a final common job.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2315>
This aims to replace the x,y arguments in wl_surface.attach(); meaning
it can be used more sanely together with EGL, and at all when using
Vulkan.
The most common use case for the offset is setting the hotspot of DND
surfaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1905>
This is to get support for the “-terminate delay” option in Xwayland
with libXfixes 6.0.
libXfixes 6.0 provides the new ClientDisconnectMode that clients can
use to declare themselves as to-be-terminated.
This can be used to let Xwayland terminate itself automatically when no
other (“non-terminatable”) X11 client is left.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
We can't just run a single 'meson' command in the script as we need to
launch multiple long running processes inside the D-Bus session:
* The meson test invokation itself
* wireplumber
This was handled for the 'test' stages, but not for the 'dist' stage,
which as a result would fail due to wireplumber not being launched
causing any test using pipewire to timeout.
Address this by making run-tests.sh a more generic run-meson.sh that
launches wireplumber before running the actual meson command.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2204>
Needs a couple of changes to make tests pass again:
* mesa-dri-drivers needs explicit installation to install swrast dri
driver
* wireplumber needs to be started inside the D-Bus session
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2142>
