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
This commit is a bit deceitful: The main change in the image is *not* the
more recent Fedora base, but an updated (and not backward-compatible)
evolution-data-server package from the fmuellner/gnome-shell-ci copr.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/501 ports
gnome-shell to the new API, so to keep mutter and gnome-shell CI
working after that change, we need to build against the correct
EDS version.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/582
While the regular session bus is provided by `dbus-run-session`, the
a11y bus is spawn by the "normal" D-Bus daemon (that is, dbus-broker
in F30). This currently fails, either due to a bug or some missing
dependencies in the container environment. But as we don't actually
need the additional bus, just disable it via the environment to make
not break tests when updating the base image to F30.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/582
Linux glibc supports a malloc implementation that is allows to be tunable using
environment variables, to check allocation issues.
When MALLOC_CHECK_ is set to 3, a diagnostic message is printed on stderr and
the program is aborted.
Setting the MALLOC_PERTURB_ environment variable causes the malloc functions in
to return memory which has been wiped and initialized with the byte value of the
environment variable.
So use this features when running tests in order to catch better memory errors.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/578
