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
