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>
So far, releases are done locally by invoking `meson dist`.
We can do better and leverage the existing CI infrastructure, to get
to the following release workflow:
- bump version in meson.build, update NEWS etc.
- open merge request for the release
- merge when the pipeline (including dist check) succeeds
- tag the release
- wait for the tag pipeline to spit out the tarball artifact
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1980>
Create a test system bus and use it to run all the tests, add a mock
SensorsProxy (via dbusmock template) server that implements the
net.hadess.SensorProxy interface.
To make testing easier, the service is created on request of a proxy for
it, whose lifetime controls the mock service lifetime as well.
This is done using a further mock service that is used to manage the
others, using python-dbusmock to simplify the handling.
Add basic tests for the orientation manager.
As per the usage dbusmock, we're now launching all the tests under such
wrapper, so that local dbus environment won't ever considered, and
there's no risk that it may affect the tests results both locally and in
CI.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233>
This job does:
1. Download the coverity bundle and untar it
2. Build mutter using clang and the coverity tool
3. Compress the coverity report
4. Upload for analysis
Things to note:
- Analysis are throttled, as per https://scan.coverity.com/faq#frequency
we qualify for 21 weekly builds, 3 daily. Mutter is sometimes a busy
project, so it seems we'd get often those consumed early in the day.
This is something we can resign to, but the times we'll try to upload
a report to have it rejected make the operation kinda pointless and
probably better throttled by ourselves.
- The task is manual, given the restrictions above.
- The task only applies on master, as the envvar holding the coverity
token is protected in gitlab.
- I had to use clang as the coverity tool doesn't seem to work ATM with
gcc as per recent Fedora.
- The coverity tarball is 1.2GB in size, which is a bit too big to have
it downloaded each time. As per their upload instructions, the tarball
gets updated twice yearly, so this is cached to minimize downloads.
- The coverity token for mutter is kept private/hidden in gitlab CI
settings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1100>
This drops some custom building of various components that are now up to
date. While at it, start using the FDO_DISTRIBUTION_PACKAGES variable to
install packages, as it with the bumped ci-templates version also
doesn't install weak dependencies.
This also requires tweaking the pipewire dead lock work arounds, as it
changed configuration file paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1865>
With the surfaceless mode in the headless backend, it's now possible to
initiate the headless mode without any mode setting devices, or render
nodes, without any special CI runner privileges.
The native backend tests include screen cast tests, so make them
possible to run by starting pipewire. Testing shows that enabling audio
support (pulseaudio & jack compat layers) makes the tests dead lock and
eventually timeout, so disable those features for now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The 0.3.21 release includes busy buffers, which are a requirement
for us to switch to cogl_framebuffer_flush() in the next commit.
Bump pipewire dependency to 0.3.21, and adjust CI to build it from
the corresponding tag.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1701>
This adds 64 bit ARM support to parts of the CI pipeline, more
specifically, we now:
- Build a 64 bit ARM container image alongside the 64 bit x86 one.
- Build test mutter on 64 bit ARM
- Run tests on 64 bit ARM
- Check coverage on 64 bit ARM
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1577>
The image registry must be enabled for the CI to work, as the container
image from the upstream registry is placed (as a reference, more or
less) in the local registry.
Recently, ci-templates got a bit more helpful if this happened, and will
fail up front and generate a JUnit report with a message describing the
issue.
Update to this version.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1587>
It's the rules that guard the pipelines, deciding when they are allowed
to run or not. The 'only_default' comes from the fact that in the past
they set the only: field.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1588>
gnome-shell depends on gdm's client library at runtime, but the
new pipeline-built image no longer provides it.
Add it back, but built it from source instead of using the Fedora
package, so we don't draw in all of gdm's runtime dependencies
(which includes a full GNOME session including gnome-shell).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1590>
ci-templates had a bug where it failed to find the ready-built container
images on the upstream repository due to invalid assumptions about the
relationship between upstream repository and image registry. This
resulted in the container image to be rebuilt, wasting valuable CPU
cycles and storage space. Bump the included ci-templates template to
include the fix for this.
See https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/22.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1583>
only/except keywords where deperecated in favor of rules.
Since we started using GNOME/mutter!1525 it introduced
a second pipeline being run for each commit.
Detached pipelines are the only way to access CI_MERGE_REQUEST_*
variables, and if we disable normal pipelines you will need to
create wip/spam MRs in order to run the tests.
This reworked rules makes it so, the normal pipeline needs manual
interaction to be started, and the detached/MR pipleines is always
run.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1578>
If review fails, it'll fail very early in the pipeline, but we won't see
the test case failure until the whole pipeline succeeds, which might be
10 minutes later.
To avoid sitting there wondering why it failed, let the time consuming
jobs wait until the review stage, which tends to take less than 20
seconds, succeeds. This way the review test result will be presented
earlier.
This changes the pipeline to run the check-commit-log job also for
non-merge requests, with the difference being that it will pass
immediately if it's not a merge request.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1549>
We're just a "ninja coverage" away from getting the full report,
it is not that much extra to the pipeline. Also, fix bugs that
accumulated since the manual task was added, e.g. let the full
built+tested tree available on the coverity stage.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1535
We only test the meson-build job, so there's no point to save artifacts for
the other test-build only builds.
So, only save meson logs artifacts (with a default gitlab expiration time)
for the other build-without-* jobs
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1236
While we don't have an high number of tests, we still have some code
coverage and so we can track this via gitlab CI, given that it supports it
natively.
So add gcovr to the DockerFile dependency, build with -Db_coverage=true
meson native parameter, and add another manual job to make ninja to generate
the coverage reports on requests or in any master or tag ref.
Keep the artifacts around to be able to browse the generated HTML files and
eventually print the text reports so that they can be parsed by gitlab.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1236
We have branched now, time for a shiny new CI image.
Update the Dockerfile to:
- switch to F32
- use a single shared copr
- drop dependencies that are now covered by builddep
- do not include weak deps
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1176
There are two common ways of building mutter: With both the native
backend and Wayland support (most common, used by most Linux distributions), and
without the native backend and Wayland support (as is done by some
BSD*s).
To catch compilation errors in both these common build configurations,
change the no-native-backend build phase to also not build with Wayland
support.
This also disables building mutter tests, as tests depend on Wayland to
run.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/837
One of the man pages is now generated using asciidoc, which is missing
from the CI image. But given that this doesn't depend on mutter in any
way, just disable man pages in the gnome-shell build instead of updating
the Dockerfile.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/740
Nobody from the core team tests that configuration, so some non-guarded
includes regularly sneak in. Avoid those build breakages by adding a
corresponding job to the CI pipeline.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/637
The point is to not initialize to some non-zero value to find places
incorrectly relying on blocks being zero initialized. Thus, there is no
reason to have a different random number each time, and by having it the
same, we have slightly more reproducable triggers, would we ever trigger
anything due to this.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/591
Otherwise tests will fail due to the following warning:
(mutter-test-runner:3700): dconf-WARNING **: 06:39:42.124: unable to
open file '/etc/dconf/db/local': Failed to open file
“/etc/dconf/db/local”: open() failed: No such file or directory; expect
degraded performance
https://gitlab.gnome.org/GNOME/mutter/merge_requests/591
