brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
mutter/.gitlab-ci.yml

98 lines
2.5 KiB
YAML
Raw Permalink Normal View History

ci: Update docker image to v3 It's this time of the cycle again: Rebase the docker image to the upcoming Fedora release, so we can drop a fair bit of the custom dependencies that have piled up. https://gitlab.gnome.org/GNOME/mutter/merge_requests/894
2019-10-29 00:50:07 +01:00
image: registry.gitlab.gnome.org/gnome/mutter/master:v3
Add .gitlab-ci.yml for build testing This adds compilation testing using meson on the gitlab instance. It uses a prebuild image built, described in .gitlab-ci/Dockerfile, based on Fedora 29. The image is build and published by running: cd .gitlab-ci/ docker build -t registry.gitlab.gnome.org/gnome/mutter/master:v1 . docker push registry.gitlab.gnome.org/gnome/mutter/master:v1 Resolves: https://gitlab.gnome.org/GNOME/mutter/merge_requests/132
2018-06-14 21:01:35 +02:00
stages:
gitlab-ci.yml: Add check for issue or MR URL This adds a pipeline stage for merge requests that checks that the commit message contains an URL to either a issue or a merge request. This means that for merge requests without corresponding issues will always fail initially, as the merge request URL is not known until after it is created. This is still arguably better than accidentally merging merge requests without URLs. https://gitlab.gnome.org/GNOME/mutter/merge_requests/440
2019-02-05 18:19:43 +01:00
- review
Add .gitlab-ci.yml for build testing This adds compilation testing using meson on the gitlab instance. It uses a prebuild image built, described in .gitlab-ci/Dockerfile, based on Fedora 29. The image is build and published by running: cd .gitlab-ci/ docker build -t registry.gitlab.gnome.org/gnome/mutter/master:v1 . docker push registry.gitlab.gnome.org/gnome/mutter/master:v1 Resolves: https://gitlab.gnome.org/GNOME/mutter/merge_requests/132
2018-06-14 21:01:35 +02:00
- build
gitlab-ci: Add test stage The test stage runs the whole meson test suite inside Xvfb inside a dbus session. Running inside Xvfb is required as the cogl, clutter and mutter tests require to run on top of X11; the dbus session is required to make mutter succeed in owning names on the bus. This also updates the Dockerfile to include packages needed for running tests. https://gitlab.gnome.org/GNOME/mutter/issues/193
2018-08-17 14:15:29 +02:00
- test
ci: Add job for pushing coverity reports 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. - Just made it apply to master, given the restrictions above. - 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 714MB 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, may also be a candidate for caching. - The coverity token for mutter is kept private/hidden in gitlab CI settings. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1100
2020-02-29 15:06:26 +01:00
- analysis
Add .gitlab-ci.yml for build testing This adds compilation testing using meson on the gitlab instance. It uses a prebuild image built, described in .gitlab-ci/Dockerfile, based on Fedora 29. The image is build and published by running: cd .gitlab-ci/ docker build -t registry.gitlab.gnome.org/gnome/mutter/master:v1 . docker push registry.gitlab.gnome.org/gnome/mutter/master:v1 Resolves: https://gitlab.gnome.org/GNOME/mutter/merge_requests/132
2018-06-14 21:01:35 +02:00
gitlab-ci.yml: Add check for issue or MR URL This adds a pipeline stage for merge requests that checks that the commit message contains an URL to either a issue or a merge request. This means that for merge requests without corresponding issues will always fail initially, as the merge request URL is not known until after it is created. This is still arguably better than accidentally merging merge requests without URLs. https://gitlab.gnome.org/GNOME/mutter/merge_requests/440
2019-02-05 18:19:43 +01:00
check-commit-log:
stage: review
ci: Ensure we clone a deep enough history for commit review It seems gitlab changed something recently in the default clone depth which made MRs with >10 commits to obscurely fail in the review stage. As per https://docs.gitlab.com/ee/ci/yaml/#shallow-cloning, bump it to 100 to allow bigger MRs. https://gitlab.gnome.org/GNOME/mutter/merge_requests/551
2019-04-24 12:24:12 +02:00
variables:
GIT_DEPTH: "100"
gitlab-ci.yml: Add check for issue or MR URL This adds a pipeline stage for merge requests that checks that the commit message contains an URL to either a issue or a merge request. This means that for merge requests without corresponding issues will always fail initially, as the merge request URL is not known until after it is created. This is still arguably better than accidentally merging merge requests without URLs. https://gitlab.gnome.org/GNOME/mutter/merge_requests/440
2019-02-05 18:19:43 +01:00
script:
- ./.gitlab-ci/check-commit-log.sh
only:
- merge_requests
Add .gitlab-ci.yml for build testing This adds compilation testing using meson on the gitlab instance. It uses a prebuild image built, described in .gitlab-ci/Dockerfile, based on Fedora 29. The image is build and published by running: cd .gitlab-ci/ docker build -t registry.gitlab.gnome.org/gnome/mutter/master:v1 . docker push registry.gitlab.gnome.org/gnome/mutter/master:v1 Resolves: https://gitlab.gnome.org/GNOME/mutter/merge_requests/132
2018-06-14 21:01:35 +02:00
build-mutter:
stage: build
script:
ci: Install to Mutter and GNOME Shell to /usr So GNOME Shell can find the pkg-config files properly. https://gitlab.gnome.org/GNOME/mutter/merge_requests/548
2019-04-23 12:33:43 -03:00
- meson . build -Dbuildtype=debugoptimized -Degl_device=true -Dwayland_eglstream=true --werror --prefix /usr
Add .gitlab-ci.yml for build testing This adds compilation testing using meson on the gitlab instance. It uses a prebuild image built, described in .gitlab-ci/Dockerfile, based on Fedora 29. The image is build and published by running: cd .gitlab-ci/ docker build -t registry.gitlab.gnome.org/gnome/mutter/master:v1 . docker push registry.gitlab.gnome.org/gnome/mutter/master:v1 Resolves: https://gitlab.gnome.org/GNOME/mutter/merge_requests/132
2018-06-14 21:01:35 +02:00
- ninja -C build
- ninja -C build install
gitlab-ci: Use artifacts to keep built data and reuse in test Make test to be dependent on build phase, saving artifacts for some time in order to just run the tests without performing any rebuild. https://gitlab.gnome.org/GNOME/mutter/merge_requests/408
2019-01-23 13:28:38 +01:00
artifacts:
ci: Test building without native backend support 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
2019-06-22 16:55:08 +02:00
expire_in: 1 day
paths:
- build
only:
- merge_requests
- /^.*$/
ci: Change the without-native-backend to not build with Wayland too 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
2019-10-09 10:42:35 +02:00
build-without-native-backend-and-wayland:
ci: Test building without native backend support 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
2019-06-22 16:55:08 +02:00
stage: build
script:
ci: Change the without-native-backend to not build with Wayland too 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
2019-10-09 10:42:35 +02:00
- meson . build -Dbuildtype=debugoptimized -Dnative_backend=false -Dudev=false -Dwayland=false -Dcore_tests=false --werror --prefix /usr
ci: Test building without native backend support 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
2019-06-22 16:55:08 +02:00
- ninja -C build
- ninja -C build install
artifacts:
gitlab-ci: Use artifacts to keep built data and reuse in test Make test to be dependent on build phase, saving artifacts for some time in order to just run the tests without performing any rebuild. https://gitlab.gnome.org/GNOME/mutter/merge_requests/408
2019-01-23 13:28:38 +01:00
expire_in: 1 day
paths:
- build
gitlab-ci.yml: Add check for issue or MR URL This adds a pipeline stage for merge requests that checks that the commit message contains an URL to either a issue or a merge request. This means that for merge requests without corresponding issues will always fail initially, as the merge request URL is not known until after it is created. This is still arguably better than accidentally merging merge requests without URLs. https://gitlab.gnome.org/GNOME/mutter/merge_requests/440
2019-02-05 18:19:43 +01:00
only:
- merge_requests
- /^.*$/
gitlab-ci: Add test stage The test stage runs the whole meson test suite inside Xvfb inside a dbus session. Running inside Xvfb is required as the cogl, clutter and mutter tests require to run on top of X11; the dbus session is required to make mutter succeed in owning names on the bus. This also updates the Dockerfile to include packages needed for running tests. https://gitlab.gnome.org/GNOME/mutter/issues/193
2018-08-17 14:15:29 +02:00
test-mutter:
stage: test
gitlab-ci: Use artifacts to keep built data and reuse in test Make test to be dependent on build phase, saving artifacts for some time in order to just run the tests without performing any rebuild. https://gitlab.gnome.org/GNOME/mutter/merge_requests/408
2019-01-23 13:28:38 +01:00
dependencies:
- build-mutter
gitlab-ci: Define exported global variables once Don't redefine XDG runtime and gsettings schema paths multiple times, just export the variables once and reuse them. https://gitlab.gnome.org/GNOME/mutter/merge_requests/408
2019-01-24 00:24:32 +01:00
variables:
XDG_RUNTIME_DIR: "$CI_PROJECT_DIR/runtime-dir"
GSETTINGS_SCHEMA_DIR: "$CI_PROJECT_DIR/build/data"
gitlab-ci: Use G_SLICE=always-malloc in tests This allows to catch errors better, as per MALLOC_CHECK_'s definition https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
2019-05-16 17:06:04 -05:00
G_SLICE: "always-malloc"
gitlab-ci: Use MALLOC_CHECK_ and MALLOC_PERTURB_ env variables in tests 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
2019-05-15 18:41:17 -05:00
MALLOC_CHECK_: "3"
ci: Disable a11y bus for tests 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
2019-05-20 18:40:34 +02:00
NO_AT_BRIDGE: "1"
ci: Make MALLOC_PERTURB_ less random 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
2019-05-24 09:18:34 +02:00
MALLOC_PERTURB_: "123"
gitlab-ci: Add test stage The test stage runs the whole meson test suite inside Xvfb inside a dbus session. Running inside Xvfb is required as the cogl, clutter and mutter tests require to run on top of X11; the dbus session is required to make mutter succeed in owning names on the bus. This also updates the Dockerfile to include packages needed for running tests. https://gitlab.gnome.org/GNOME/mutter/issues/193
2018-08-17 14:15:29 +02:00
script:
ci: Run dconf update before running tests 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
2019-05-24 08:48:23 +02:00
- dconf update
gitlab-ci: Define exported global variables once Don't redefine XDG runtime and gsettings schema paths multiple times, just export the variables once and reuse them. https://gitlab.gnome.org/GNOME/mutter/merge_requests/408
2019-01-24 00:24:32 +01:00
- mkdir -m 700 $XDG_RUNTIME_DIR
- glib-compile-schemas $GSETTINGS_SCHEMA_DIR
gitlab-ci: Use artifacts to keep built data and reuse in test Make test to be dependent on build phase, saving artifacts for some time in order to just run the tests without performing any rebuild. https://gitlab.gnome.org/GNOME/mutter/merge_requests/408
2019-01-23 13:28:38 +01:00
- >
dbus-run-session -- xvfb-run -s '+iglx -noreset'
gitlab-ci: Print error logs on failures https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
2019-05-16 17:06:47 -05:00
meson test -C build --no-rebuild -t 10 --verbose --no-stdsplit --print-errorlogs --wrap catchsegv
gitlab-ci.yml: Add check for issue or MR URL This adds a pipeline stage for merge requests that checks that the commit message contains an URL to either a issue or a merge request. This means that for merge requests without corresponding issues will always fail initially, as the merge request URL is not known until after it is created. This is still arguably better than accidentally merging merge requests without URLs. https://gitlab.gnome.org/GNOME/mutter/merge_requests/440
2019-02-05 18:19:43 +01:00
only:
- merge_requests
- /^.*$/
ci: Build GNOME Shell at the test stage Hopefully this will allow us prevent merging branches that accidentally break GNOME Shell. https://gitlab.gnome.org/GNOME/mutter/merge_requests/548
2019-04-22 14:54:11 -03:00
can-build-gnome-shell:
stage: test
dependencies:
- build-mutter
before_script:
- meson install --no-rebuild -C build
script:
- .gitlab-ci/checkout-gnome-shell.sh
ci: Don't build gnome-shell's man pages 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
2019-08-21 22:30:41 +02:00
- meson gnome-shell gnome-shell/build --prefix /usr -Dman=false
ci: Build GNOME Shell at the test stage Hopefully this will allow us prevent merging branches that accidentally break GNOME Shell. https://gitlab.gnome.org/GNOME/mutter/merge_requests/548
2019-04-22 14:54:11 -03:00
- ninja -C gnome-shell/build install
only:
- merge_requests
- /^.*$/
ci: Add job for pushing coverity reports 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. - Just made it apply to master, given the restrictions above. - 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 714MB 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, may also be a candidate for caching. - The coverity token for mutter is kept private/hidden in gitlab CI settings. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1100
2020-02-29 15:06:26 +01:00
coverity:
stage: analysis
allow_failure: true
script:
- dnf install -y clang
- curl https://scan.coverity.com/download/linux64 --data "token=$COVERITY_TOKEN&project=mutter" --output /tmp/coverity_tool.tgz
- tar zxf /tmp/coverity_tool.tgz
- CC=clang meson coverity-build
- ./cov-analysis-linux64-*/bin/cov-build --dir cov-int ninja -C coverity-build
- tar czf cov-int.tar.gz cov-int
- curl https://scan.coverity.com/builds?project=mutter
--form token=$COVERITY_TOKEN --form email=carlosg@gnome.org
--form file=@cov-int.tar.gz --form version="`git describe --tags`"
--form description="gitlab CI build"
only:
- master
Reference in New Issue Copy Permalink