luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-02-23 18:52:09 +01:00
Code Issues Packages Projects Releases Wiki Activity
glib/.gitlab-ci.yml

300 lines
8.8 KiB
YAML
Raw Normal View History

ci: Add GitLab CI description file We're mostly interested into building and testing everything that gets pushed to the repository — including merge requests. When pushing tags, though, we should assume we're spinning a release, so let's run the dist target, and store the tarball, and the generated documentation while we're at it, as artifacts on GitLab. The Dockerfile for the image used for the build is included in tree, and published on Docker Hub. Using a custom image allows us to avoid the costly "download and install build dependencies" phase, as well as controlling the environment a little bit better. https://bugzilla.gnome.org/show_bug.cgi?id=793635
2018-02-18 14:59:29 +00:00
stages:
- build
ci: collect test coverage and deploy a html report through gitlab pages Use lcov for both Fedora and MSYS2 to create coverage reports and add a second ci stage which merges the coverage and creates a html report using genhtml. In the final stage, which is only run on master, the result is published on gitlab pages. https://bugzilla.gnome.org/show_bug.cgi?id=795636
2018-04-27 17:04:52 +02:00
- coverage
ci: Add scan-build job in a new ‘analysis’ pipeline stage Use Meson’s support for running scan-build (Clang’s static analyser) against the build, so that we get static analysis of each pipeline. Add it in a new pipeline stage, after code coverage, so that we don’t waste resources on it unless the unit tests pass — a static analysis build takes perhaps 10× as long as a normal GCC build. https://mesonbuild.com/howtox.html#use-clang-static-analyzer Currently, the static analysis results are uploaded as artifacts, but the job will always succeed (regardless of whether there are any bugs found in the analysis). Currently, a large number of reports are outputted by the analyser, which need to be fixed before we can gate the pipeline on it. Furthermore, in order to get scan-build to exit with a non-zero status if any bugs are found, we need to depend on Meson ≥ 0.49.0, which contains the fix https://github.com/mesonbuild/meson/issues/4334, allowing us to add the following to .gitlab-ci.yml: ``` variables: # Exit with a non-zero status if any bugs are found SCANBUILD: "scan-build --status-bugs" ``` Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-27 23:32:39 +00:00
- analysis
ci: collect test coverage and deploy a html report through gitlab pages Use lcov for both Fedora and MSYS2 to create coverage reports and add a second ci stage which merges the coverage and creates a html report using genhtml. In the final stage, which is only run on master, the result is published on gitlab pages. https://bugzilla.gnome.org/show_bug.cgi?id=795636
2018-04-27 17:04:52 +02:00
- deploy
ci: Open issues when scheduled pipelines fails It's hard to track failures on scheduled pipelines, so make gitlab open an issue for us if that happens.
2022-10-31 02:46:31 +01:00
- report
ci: Add GitLab CI description file We're mostly interested into building and testing everything that gets pushed to the repository — including merge requests. When pushing tags, though, we should assume we're spinning a release, so let's run the dist target, and store the tarball, and the generated documentation while we're at it, as artifacts on GitLab. The Dockerfile for the image used for the build is included in tree, and published on Docker Hub. Using a custom image allows us to avoid the costly "download and install build dependencies" phase, as well as controlling the environment a little bit better. https://bugzilla.gnome.org/show_bug.cgi?id=793635
2018-02-18 14:59:29 +00:00
gitlab-ci: Add 32bit MinGW jobs using MSYS2 This builds glib using meson/ninja/ccache with mingw-w64 on a Windows machine. The CI scripts expect a gitlab runner to exist with the "win32" tag which uses the default "cmd" shell by default. Before running the tests pacman is invoked to update the system (potentially including bash etc, thus the extra step) Then a login shell is started with CHERE_INVOKING to not change the cwd and finally the test script is executed. https://bugzilla.gnome.org/show_bug.cgi?id=793729
2018-02-22 19:37:16 +01:00
cache:
paths:
- _ccache/
ci: unify the test timeout multiplier across jobs Introduce a MESON_TEST_TIMEOUT_MULTIPLIER env var and use it in all test scripts.
2018-05-26 20:17:15 +02:00
variables:
ci: Update images to cache wrap downloads We aren't allowed to download wraps in the build, and we need them on Android and MinGW
2022-12-31 02:15:13 +05:30
FEDORA_IMAGE: "registry.gitlab.gnome.org/gnome/glib/fedora:v20"
Revert "build: Bump Meson dependency to 0.64.0" This reverts commit 91f14cd058555f16b5abef1a577332921b08497b. The freedesktop SDK, which is used by gnome-build-meta, only has Meson 0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment, GLib is not buildable in gnome-build-meta and hence can’t be tested in nightly pipelines against other projects, etc. That’s bad for testing GLib. It’s arguably bad that we’re restricted to using an older version of Meson than shipped by Debian Testing, but that’s a separate discussion to be had. Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥ 0.64. This also means reverting the simplifications to use of `gnome.mkenum_simple()`. See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
2022-11-24 12:10:07 +00:00
COVERITY_IMAGE: "registry.gitlab.gnome.org/gnome/glib/coverity:v7"
DEBIAN_IMAGE: "registry.gitlab.gnome.org/gnome/glib/debian-stable:v14"
ci: Update images to cache wrap downloads We aren't allowed to download wraps in the build, and we need them on Android and MinGW
2022-12-31 02:15:13 +05:30
MINGW_IMAGE: "registry.gitlab.gnome.org/gnome/glib/mingw:v10"
meson: Use default test multiplier to define timeouts So that we don't have to care about the default, being always set to 1m
2022-10-20 03:16:30 +02:00
MESON_TEST_TIMEOUT_MULTIPLIER: 4
Fix failing tests when G_MESSAGES_DEBUG is set (again) Similar issue was fixed with commit f929d148, but it's happening again. Define G_MESSAGES_DEBUG=all when running CI to ensure we won't regress anymore.
2018-08-16 14:31:55 -04:00
G_MESSAGES_DEBUG: all
build: Drop checks and workarounds for older Meson versions Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-05-05 19:24:30 +01:00
MESON_COMMON_OPTIONS: "--buildtype debug --wrap-mode=nodownload --fatal-meson-warnings"
ci: unify the test timeout multiplier across jobs Introduce a MESON_TEST_TIMEOUT_MULTIPLIER env var and use it in all test scripts.
2018-05-26 20:17:15 +02:00
ci: Use extends rather than YAML anchors for `only-default` This makes things slightly more extensible in future, but introduces no functional differences right now. See https://docs.gitlab.com/ce/ci/yaml/README.html#extends. Suggested by Jordan Petridis. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-11-28 11:38:25 +00:00
.only-default:
ci: Factor out only/except properties from jobs We can use a template to factor these out and make things a bit more maintainable. This should introduce no functional changes. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-11-27 11:06:32 +00:00
only:
- branches
except:
- tags
ci: Factor out a template for jobs which run only on the origin repo This clarifies the intent of the `branches@GNOME/glib` selector. It introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:44:45 +00:00
# Some jobs run on CI runners which don’t have good isolation between CI jobs,
# and don’t have much available resource. Limit those jobs to only ones on the
# origin repository (GNOME/glib), rather than people’s forks. Code in the origin
# repository can be trusted.
.only-origin:
only:
- branches@GNOME/glib
except:
- tags
ci: Move some CI jobs from branches to schedules These jobs (`scan-build` and `valgrind`) take ages to run and rarely indicate failures, so move them to a weekly schedule, rather than running them on each branch/MR. The current schedule is once weekly: https://gitlab.gnome.org/GNOME/glib/-/pipeline_schedules. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 11:54:58 +01:00
# Some jobs take a long time and are unlikely to find failures (or will find
# failures which are not merge-blockers to fix), so they’re executed on a weekly
# schedule in order to save CI resources and speed up branch pipelines.
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
.only-schedules:
ci: Move some CI jobs from branches to schedules These jobs (`scan-build` and `valgrind`) take ages to run and rarely indicate failures, so move them to a weekly schedule, rather than running them on each branch/MR. The current schedule is once weekly: https://gitlab.gnome.org/GNOME/glib/-/pipeline_schedules. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 11:54:58 +01:00
only:
- schedules
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
except:
- tags
ci: Rename .build template to .build-linux This name is more specific to what the template actually does. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:33:09 +00:00
.build-linux:
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
before_script:
- bash .gitlab-ci/show-execution-environment.sh
- cp -r $HOME/subprojects/* subprojects/
ci: Move some CI jobs from branches to schedules These jobs (`scan-build` and `valgrind`) take ages to run and rarely indicate failures, so move them to a weekly schedule, rather than running them on each branch/MR. The current schedule is once weekly: https://gitlab.gnome.org/GNOME/glib/-/pipeline_schedules. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 11:54:58 +01:00
ci: Run installed-tests on Fedora Run installed-tests on a Fedora system.
2019-11-15 11:59:00 +01:00
installed-tests:
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
extends:
ci: Rename .build template to .build-linux This name is more specific to what the template actually does. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:33:09 +00:00
- .build-linux
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
- .only-schedules
ci: Use variables for docker images
2020-01-13 12:45:00 -05:00
image: $FEDORA_IMAGE
ci: Run installed-tests on Fedora Run installed-tests on a Fedora system.
2019-11-15 11:59:00 +01:00
stage: build
ci: Add DAG attributes Add some basic DAG attributes so that some jobs in the pipeline can run out of stage order to speed things up a little. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:00:57 +01:00
needs: []
ci: Run installed-tests on Fedora Run installed-tests on a Fedora system.
2019-11-15 11:59:00 +01:00
script:
# dtrace is disabled because it breaks the static-link.py test
- meson ${MESON_COMMON_OPTIONS}
--werror
--prefix=/usr --libdir=/usr/lib64
-Dinstalled_tests=true
-Ddefault_library=both
-Ddtrace=false
_build
- ninja -C _build
- sudo ninja -C _build install
guri: new URI parsing and generating functions Add a set of new URI parsing and generating functions, including a new parsed-URI type GUri. Move all the code from gurifuncs.c into guri.c, reimplementing some of those functions (and g_string_append_uri_encoded()) in terms of the new code. Fixes: https://gitlab.gnome.org/GNOME/glib/issues/110 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2019-01-17 10:38:20 +04:00
# Remove old headers, possibly present in current installation
- sudo rm -f /usr/include/glib-2.0/glib/gurifuncs.h
ci: Fix permission error in valgrind analysis stage The valgrind analysis stage inherits from existing artefacts, so make sure to reset the permissions on the glib build directory to avoid a new build failing. $ meson ${MESON_COMMON_OPTIONS} --werror -Dsystemtap=true -Ddtrace=true -Dfam=true -Dinstalled_tests=true _build <snip> PermissionError: [Errno 13] Permission denied: '/builds/GNOME/glib/_build/meson-logs/meson-log.txt'
2019-12-11 17:52:24 +01:00
- sudo chown -R `id -un`:`id -gn` _build/
ci: Work-around successful installed tests having no logs This works around a bug in gnome-desktop-testing. See: https://gitlab.gnome.org/GNOME/gnome-desktop-testing/merge_requests/2
2019-12-04 14:33:47 +01:00
# Work-around https://gitlab.gnome.org/GNOME/gnome-desktop-testing/merge_requests/2
- mkdir -p _build/installed-tests-report/logs/
tests: Don't skip static-link test Set GLIB_TEST_COMPILATION=1 envvar so that the static-link test is run.
2019-11-28 14:30:23 +01:00
- GLIB_TEST_COMPILATION=1 gnome-desktop-testing-runner
ci: Run installed-tests on Fedora Run installed-tests on a Fedora system.
2019-11-15 11:59:00 +01:00
--report-directory=_build/installed-tests-report/failed/
ci: Log successes for installed-tests as well Use newer version of gnome-desktop-testing to log test results even if successful.
2019-11-28 15:21:33 +01:00
--log-directory=_build/installed-tests-report/logs/
ci: Enable parallelisation when running installed tests This should speed up CI runs significantly, as the installed tests are currently running in series. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-02-24 11:06:00 +00:00
--parallel=0
ci: Run installed-tests on Fedora Run installed-tests on a Fedora system.
2019-11-15 11:59:00 +01:00
glib
artifacts:
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
when: always
ci: Expire CI artifacts after 1 week The default is 30 days, but we don’t need them around that long. This should free up some disk space on the GitLab/CI runner systems. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-04-06 12:54:54 +01:00
expire_in: 1 week
ci: Run installed-tests on Fedora Run installed-tests on a Fedora system.
2019-11-15 11:59:00 +01:00
paths:
- "_build/config.h"
- "_build/glib/glibconfig.h"
- "_build/meson-logs"
- "_build/installed-tests-report/"
ci: Add a build with G_DISABLE_ASSERT defined We want GLib to build correctly with this defined, and for all its tests to still pass. Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #1708
2019-03-05 11:02:24 +00:00
G_DISABLE_ASSERT:
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
extends:
ci: Rename .build template to .build-linux This name is more specific to what the template actually does. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:33:09 +00:00
- .build-linux
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
- .only-schedules
ci: Use variables for docker images
2020-01-13 12:45:00 -05:00
image: $FEDORA_IMAGE
ci: Add a build with G_DISABLE_ASSERT defined We want GLib to build correctly with this defined, and for all its tests to still pass. Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #1708
2019-03-05 11:02:24 +00:00
stage: build
ci: Add DAG attributes Add some basic DAG attributes so that some jobs in the pipeline can run out of stage order to speed things up a little. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:00:57 +01:00
needs: []
ci: Add a build with G_DISABLE_ASSERT defined We want GLib to build correctly with this defined, and for all its tests to still pass. Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #1708
2019-03-05 11:02:24 +00:00
script:
- meson ${MESON_COMMON_OPTIONS}
--werror
-Dsystemtap=true
-Ddtrace=true
-Dinstalled_tests=true
Meson: Add glib_checks and glib_asserts options In cases where performance are critical it can be useful to disable checks and asserts. GStreamer has those options too, using the same name and setting them yielding means we can set those options on the main project (e.g. gst-build) and glib will inherit the same value when built as subproject.
2020-04-08 15:14:31 -04:00
-Dglib_assert=false
ci: Add a build with G_DISABLE_ASSERT defined We want GLib to build correctly with this defined, and for all its tests to still pass. Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #1708
2019-03-05 11:02:24 +00:00
_build
- ninja -C _build
ci: Generate a cover report for the test suite GitLab can show the results of a CI pipeline if the pipeline generates a report using the JUnit XML format. Since Meson provides a machine parseable output for `meson test`, we can take that and turn it into XML soup.
2019-04-05 20:53:11 +01:00
- bash -x ./.gitlab-ci/run-tests.sh
ci: Add a build with G_DISABLE_ASSERT defined We want GLib to build correctly with this defined, and for all its tests to still pass. Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #1708
2019-03-05 11:02:24 +00:00
artifacts:
ci: Generate a cover report for the test suite GitLab can show the results of a CI pipeline if the pipeline generates a report using the JUnit XML format. Since Meson provides a machine parseable output for `meson test`, we can take that and turn it into XML soup.
2019-04-05 20:53:11 +01:00
reports:
meson, ci: Support tests that can fail under certain conditions We have tests that are failing in some environments, but it's difficult to handle them because: - for some environments we just allow all the tests to fail: DANGEROUS - when we don't allow failures we have flacky tests: A CI pain So, to avoid this and ensure that: - New failing tests are tracked in all platforms - gitlab integration on tests reports is working - coverage is reported also for failing tests Add support for `can_fail` keyword on tests that would mark the test as part of the `failing` test suite. Not adding the suite directly when defining the tests as this is definitely simpler and allows to define conditions more clearly (see next commits). Now, add a default test setup that does not run the failing and flaky tests by default (not to bother distributors with testing well-known issues) and eventually run all the tests in CI: - Non-flaky tests cannot fail in all platforms - Failing and Flaky tests can fail In both cases we save the test reports so that gitlab integration is preserved.
2022-10-19 20:08:15 +02:00
junit:
- _build/meson-logs/testlog.junit.xml
- _build/meson-logs/testlog-*.junit.xml
ci: Add a build with G_DISABLE_ASSERT defined We want GLib to build correctly with this defined, and for all its tests to still pass. Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #1708
2019-03-05 11:02:24 +00:00
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
when: always
ci: Expire CI artifacts after 1 week The default is 30 days, but we don’t need them around that long. This should free up some disk space on the GitLab/CI runner systems. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-04-06 12:54:54 +01:00
expire_in: 1 week
ci: Add a build with G_DISABLE_ASSERT defined We want GLib to build correctly with this defined, and for all its tests to still pass. Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #1708
2019-03-05 11:02:24 +00:00
paths:
- "_build/config.h"
- "_build/glib/glibconfig.h"
- "_build/meson-logs"
ci: Add valgrind memcheck support on Fedora Add a separate CI job which runs memcheck on the unit tests. This is done as a separate job from the main build, since we don’t want it to interact with code coverage at all. Currently, failure of this job is ignored. Issue #333 will eventually fix that. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #487
2018-06-26 17:23:09 +01:00
valgrind:
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
extends:
ci: Rename .build template to .build-linux This name is more specific to what the template actually does. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:33:09 +00:00
- .build-linux
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
- .only-schedules
ci: Use variables for docker images
2020-01-13 12:45:00 -05:00
image: $FEDORA_IMAGE
ci: Add valgrind memcheck support on Fedora Add a separate CI job which runs memcheck on the unit tests. This is done as a separate job from the main build, since we don’t want it to interact with code coverage at all. Currently, failure of this job is ignored. Issue #333 will eventually fix that. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #487
2018-06-26 17:23:09 +01:00
stage: analysis
ci: Add DAG attributes Add some basic DAG attributes so that some jobs in the pipeline can run out of stage order to speed things up a little. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:00:57 +01:00
needs: []
ci: Add valgrind memcheck support on Fedora Add a separate CI job which runs memcheck on the unit tests. This is done as a separate job from the main build, since we don’t want it to interact with code coverage at all. Currently, failure of this job is ignored. Issue #333 will eventually fix that. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #487
2018-06-26 17:23:09 +01:00
variables:
ci: Increase the valgrind job meson test timeout There are some test failing because there's not enough time to complete, so let's give them some more time.
2022-09-02 20:41:40 +02:00
MESON_TEST_TIMEOUT_MULTIPLIER: 15
ci: Add valgrind memcheck support on Fedora Add a separate CI job which runs memcheck on the unit tests. This is done as a separate job from the main build, since we don’t want it to interact with code coverage at all. Currently, failure of this job is ignored. Issue #333 will eventually fix that. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #487
2018-06-26 17:23:09 +01:00
script:
- meson ${MESON_COMMON_OPTIONS}
--werror
-Dsystemtap=true
-Ddtrace=true
-Dinstalled_tests=true
_build
- ninja -C _build
ci: Try reducing FD soft limit to fix valgrind tests They are [currently failing](https://gitlab.gnome.org/GNOME/glib/-/jobs/2032874) with the error: ``` 1/273 glib:glib / array-test FAIL 0.19s killed by signal 11 SIGSEGV 05:04:16 G_DEBUG=gc-friendly G_TEST_BUILDDIR=/builds/GNOME/glib/_build/glib/tests MALLOC_CHECK_=2 MALLOC_PERTURB_=133 G_TEST_SRCDIR=/builds/GNOME/glib/glib/tests valgrind --tool=memcheck --error-exitcode=1 --track-origins=yes --leak-check=full --leak-resolution=high --num-callers=50 --show-leak-kinds=definite,possible --show-error-list=yes --suppressions=/builds/GNOME/glib/tools/glib.supp /builds/GNOME/glib/_build/glib/tests/array-test ----------------------------------- output ----------------------------------- stderr: valgrind: m_libcfile.c:66 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed. ------------------------------------------------------------------------------ ``` I’m not really sure what that means, but `show-execution-environment.sh` says the FD soft limit is set to 524288 on the CI machine. That seems high; on my machine it’s only 1024 (and the valgrind tests pass). So let’s try 1024. The valgrind CI has been failing since we most recently upgraded the CI image to a new version of Fedora. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-01 14:48:34 +01:00
# Valgrind doesn’t work when the soft FD limit is set too high
# See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2710
- ulimit -Sn 1024
ci: Add valgrind memcheck support on Fedora Add a separate CI job which runs memcheck on the unit tests. This is done as a separate job from the main build, since we don’t want it to interact with code coverage at all. Currently, failure of this job is ignored. Issue #333 will eventually fix that. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #487
2018-06-26 17:23:09 +01:00
- bash -x ./.gitlab-ci/run-tests.sh
build: Use add_test_setup() to allow tests to be run under valgrind This means we can specify the standard options for testing GLib under valgrind consistently, so that developers can use `meson test --setup=valgrind` to run them. Port the existing valgrind CI to use them (this will not change its functional behaviour). Suggested by Marco Trevisan at https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2717#note_1478891. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-16 11:01:04 +01:00
--setup valgrind
ci: Add valgrind memcheck support on Fedora Add a separate CI job which runs memcheck on the unit tests. This is done as a separate job from the main build, since we don’t want it to interact with code coverage at all. Currently, failure of this job is ignored. Issue #333 will eventually fix that. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #487
2018-06-26 17:23:09 +01:00
--no-suite slow
artifacts:
reports:
gitlab-ci: left-over from junit cleanup This should have been part of GNOME/glib!2686 (sorry!) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-05-25 15:27:08 +02:00
junit: "_build/meson-logs/testlog-valgrind.junit.xml"
ci: Add valgrind memcheck support on Fedora Add a separate CI job which runs memcheck on the unit tests. This is done as a separate job from the main build, since we don’t want it to interact with code coverage at all. Currently, failure of this job is ignored. Issue #333 will eventually fix that. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #487
2018-06-26 17:23:09 +01:00
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
when: always
ci: Expire CI artifacts after 1 week The default is 30 days, but we don’t need them around that long. This should free up some disk space on the GitLab/CI runner systems. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-04-06 12:54:54 +01:00
expire_in: 1 week
ci: Add valgrind memcheck support on Fedora Add a separate CI job which runs memcheck on the unit tests. This is done as a separate job from the main build, since we don’t want it to interact with code coverage at all. Currently, failure of this job is ignored. Issue #333 will eventually fix that. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #487
2018-06-26 17:23:09 +01:00
paths:
- "_build/config.h"
- "_build/glib/glibconfig.h"
- "_build/meson-logs"
ci: Rename .cross-template to .cross-build-linux This makes the name a bit more descriptive, and makes it match the rest of the naming scheme. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:34:20 +00:00
.cross-build-linux:
ci: Rename .build template to .build-linux This name is more specific to what the template actually does. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:33:09 +00:00
extends: .build-linux
Add Android CI This adds to the CI a cross build for Android NDK r16 API 21 (because thats what GStreamer currently use) for arm64. GNU iconv must be built manually into our docker image because Android NDK doesn't seems to ship it. The latest NDK r17 API 28 has iconv.h but iconv_open() symbol isn't found by the linker. Looks like broken NDK. libffi also needs to be built manually because the meson subproject doesn't support building for Android platform. It needs a recent RC release because latest stable release is 4 years old and fails to build. Fixes #1385.
2018-05-20 00:14:56 -04:00
stage: build
ci: Add DAG attributes Add some basic DAG attributes so that some jobs in the pipeline can run out of stage order to speed things up a little. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:00:57 +01:00
needs: []
Add Android CI This adds to the CI a cross build for Android NDK r16 API 21 (because thats what GStreamer currently use) for arm64. GNU iconv must be built manually into our docker image because Android NDK doesn't seems to ship it. The latest NDK r17 API 28 has iconv.h but iconv_open() symbol isn't found by the linker. Looks like broken NDK. libffi also needs to be built manually because the meson subproject doesn't support building for Android platform. It needs a recent RC release because latest stable release is 4 years old and fails to build. Fixes #1385.
2018-05-20 00:14:56 -04:00
artifacts:
ci: Be consistent on artifact naming
2018-06-05 14:01:53 -04:00
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
when: always
ci: Expire CI artifacts after 1 week The default is 30 days, but we don’t need them around that long. This should free up some disk space on the GitLab/CI runner systems. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-04-06 12:54:54 +01:00
expire_in: 1 week
Add Android CI This adds to the CI a cross build for Android NDK r16 API 21 (because thats what GStreamer currently use) for arm64. GNU iconv must be built manually into our docker image because Android NDK doesn't seems to ship it. The latest NDK r17 API 28 has iconv.h but iconv_open() symbol isn't found by the linker. Looks like broken NDK. libffi also needs to be built manually because the meson subproject doesn't support building for Android platform. It needs a recent RC release because latest stable release is 4 years old and fails to build. Fixes #1385.
2018-05-20 00:14:56 -04:00
paths:
ci: Be consistent on artifact naming
2018-06-05 14:01:53 -04:00
- "_build/meson-logs"
Add Android CI This adds to the CI a cross build for Android NDK r16 API 21 (because thats what GStreamer currently use) for arm64. GNU iconv must be built manually into our docker image because Android NDK doesn't seems to ship it. The latest NDK r17 API 28 has iconv.h but iconv_open() symbol isn't found by the linker. Looks like broken NDK. libffi also needs to be built manually because the meson subproject doesn't support building for Android platform. It needs a recent RC release because latest stable release is 4 years old and fails to build. Fixes #1385.
2018-05-20 00:14:56 -04:00
WIP: ci: Add macOS CI runner We had one before, but the runner machine was too flaky to be useful. Re-add it now that the Foundation have sorted out a more reliable machine. (Thanks!) Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #1416
2019-12-10 12:45:51 +00:00
Revert "Merge branch 'wip/pwithnall/macos-ci-disable' into 'master'" This reverts merge request !1939
2021-02-12 19:41:11 +00:00
macos:
ci: Factor out a template for jobs which run only on the origin repo This clarifies the intent of the `branches@GNOME/glib` selector. It introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:44:45 +00:00
extends: .only-origin
WIP: ci: Add macOS CI runner We had one before, but the runner machine was too flaky to be useful. Re-add it now that the Foundation have sorted out a more reliable machine. (Thanks!) Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #1416
2019-12-10 12:45:51 +00:00
stage: build
tags:
- macos
ci: Add DAG attributes Add some basic DAG attributes so that some jobs in the pipeline can run out of stage order to speed things up a little. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:00:57 +01:00
needs: []
ci: Ensure git submodules are updated before running macOS CI Since the macOS CI jobs are run on a machine which isn’t using a pre-made container image, we can’t ship a cached version of the subproject, so it has to be pulled as a git submodule. GitLab doesn’t do that by default unless you set `GIT_SUBMODULE_STRATEGY` to something other than `none`. See https://docs.gitlab.com/ee/ci/git_submodules.html Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-30 01:31:02 +01:00
variables:
GIT_SUBMODULE_STRATEGY: normal
ci: use clone mode
2023-04-21 14:50:28 +02:00
GIT_STRATEGY: clone
ci: Specify -Wno-overlength-strings on macOS This disables the following warning, which was causing CI failures on macOS when building the libpcre2 subproject: ``` ../subprojects/pcre2-10.40/src/pcre2_error.c:66:3: error: string literal of length 4380 exceeds maximum length 4095 that ISO C99 compilers are required to support [-Werror,-Woverlength-strings] ``` We don’t want to explicitly rely on using overlength strings in GLib, which is why this change is a `CFLAGS` in the CI configuration, rather than setting a project-level argument in `meson.build`. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-07-12 14:16:23 +01:00
# libpcre2 gets built as a subproject, but the default Clang options on
# macOS limit string lengths to 4095B — pcre2_error.c has a string of length
# 4380B
CFLAGS: '-Wno-overlength-strings'
WIP: ci: Add macOS CI runner We had one before, but the runner machine was too flaky to be useful. Re-add it now that the Foundation have sorted out a more reliable machine. (Thanks!) Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #1416
2019-12-10 12:45:51 +00:00
before_script:
CI: Show execution environment before we start This will help to debug CI issues that are related to us running in a container that might have unusual capabilities, mount points, filesystems etc., such as (probably) #2027, #2028, #2029. Signed-off-by: Simon McVittie <smcv@collabora.com>
2020-02-12 14:35:54 +00:00
- bash .gitlab-ci/show-execution-environment.sh
ci: Use Meson 1.0.0 on Windows and macOS CI builds This is a departure from our policy of using the minimum required Meson version, but I think it might be worth a try to see if it fixes the persistent intermittent build failures on these platforms due to what looks like build dependency graph issues. For example: - https://gitlab.gnome.org/GNOME/glib/-/jobs/2579411 - https://gitlab.gnome.org/GNOME/glib/-/jobs/2578792 - https://gitlab.gnome.org/GNOME/glib/-/jobs/2579220 - https://gitlab.gnome.org/pwithnall/glib/-/jobs/2588507 I was looking at trying to diagnose some of these failures in order to potentially file bugs against Meson, but the first step is really to test against the latest version of Meson. So here we are. Crucially, our other CI jobs continue to use the minimum Meson version required by GLib, so we continue to test that GLib builds with its minimum dependencies. I do not plan to change that. Also crucially, this MR continues to use a specific Meson version, rather than asking `pip` to install the latest available. Doing that could lead to unexpected regressions in future, and that’s not what GLib’s CI is meant to be testing for. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-02-16 13:29:54 +00:00
- pip3 install --user meson==1.0.0
WIP: ci: Add macOS CI runner We had one before, but the runner machine was too flaky to be useful. Re-add it now that the Foundation have sorted out a more reliable machine. (Thanks!) Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #1416
2019-12-10 12:45:51 +00:00
- pip3 install --user ninja
- export PATH=/Users/gitlabrunner/Library/Python/3.7/bin:$PATH
script:
ci: Use --wrap-mode=default on macOS CI runner (only) This is a partial revert of commit 595e12b5fb for macOS only, since we can’t run a VM image on that CI runner, and hence can’t easily pre-populate it with cached dependencies. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-01-20 15:30:44 +00:00
# FIXME: Use --wrap-mode=default so we download dependencies each time,
# until the macOS runner is a VM where we can use a pre-made image which
# already contains the dependencies. See:
# - https://gitlab.gnome.org/GNOME/glib/merge_requests/388
# - https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/225
WIP: ci: Add macOS CI runner We had one before, but the runner machine was too flaky to be useful. Re-add it now that the Foundation have sorted out a more reliable machine. (Thanks!) Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #1416
2019-12-10 12:45:51 +00:00
- meson ${MESON_COMMON_OPTIONS}
ci: Use --wrap-mode=default on macOS CI runner (only) This is a partial revert of commit 595e12b5fb for macOS only, since we can’t run a VM image on that CI runner, and hence can’t easily pre-populate it with cached dependencies. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-01-20 15:30:44 +00:00
--wrap-mode=default
ci: Enable --werror on macOS There are no compiler warnings when building on macOS CI at the moment, so let’s keep it that way by turning any future ones into errors. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-11-17 15:43:59 +00:00
--werror
WIP: ci: Add macOS CI runner We had one before, but the runner machine was too flaky to be useful. Re-add it now that the Foundation have sorted out a more reliable machine. (Thanks!) Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #1416
2019-12-10 12:45:51 +00:00
_build
Do not build all
2023-04-21 15:02:58 +02:00
# - ninja -C _build
tests: Stop ignoring test failures on macOS Test failures were previously ignored on macOS because there are 12 tests which consistently fail (and have not yet been fixed, because there are no regularly active macOS maintainers for GLib; you could help here!). However, this means that new test failures can’t be spotted. So, explicitly mark those 12 tests as `should_fail` on macOS, and then make other test failures cause failure of the CI run. We can track the process of fixing those 12 tests on #1392 and #1251. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #1392
2022-02-17 23:01:35 +00:00
- .gitlab-ci/run-tests.sh
ci: Enable CI on FreeBSD 12
2019-06-24 22:55:36 +08:00
artifacts:
ci: Generate a cover report for the test suite GitLab can show the results of a CI pipeline if the pipeline generates a report using the JUnit XML format. Since Meson provides a machine parseable output for `meson test`, we can take that and turn it into XML soup.
2019-04-05 20:53:11 +01:00
reports:
meson, ci: Support tests that can fail under certain conditions We have tests that are failing in some environments, but it's difficult to handle them because: - for some environments we just allow all the tests to fail: DANGEROUS - when we don't allow failures we have flacky tests: A CI pain So, to avoid this and ensure that: - New failing tests are tracked in all platforms - gitlab integration on tests reports is working - coverage is reported also for failing tests Add support for `can_fail` keyword on tests that would mark the test as part of the `failing` test suite. Not adding the suite directly when defining the tests as this is definitely simpler and allows to define conditions more clearly (see next commits). Now, add a default test setup that does not run the failing and flaky tests by default (not to bother distributors with testing well-known issues) and eventually run all the tests in CI: - Non-flaky tests cannot fail in all platforms - Failing and Flaky tests can fail In both cases we save the test reports so that gitlab integration is preserved.
2022-10-19 20:08:15 +02:00
junit:
- _build/meson-logs/testlog.junit.xml
- _build/meson-logs/testlog-*.junit.xml
ci: Add FreeBSD CI We use 'freebsd-11' instead of 'freebsd' as tags here because newer FreeBSD versions can include API changes which are worth testing.
2018-05-24 23:14:25 +08:00
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
when: always
ci: Expire CI artifacts after 1 week The default is 30 days, but we don’t need them around that long. This should free up some disk space on the GitLab/CI runner systems. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-04-06 12:54:54 +01:00
expire_in: 1 week
ci: Add FreeBSD CI We use 'freebsd-11' instead of 'freebsd' as tags here because newer FreeBSD versions can include API changes which are worth testing.
2018-05-24 23:14:25 +08:00
paths:
ci: Enable FreeBSD CI
2018-09-29 01:01:12 +08:00
- "_build/config.h"
- "_build/glib/glibconfig.h"
ci: Add FreeBSD CI We use 'freebsd-11' instead of 'freebsd' as tags here because newer FreeBSD versions can include API changes which are worth testing.
2018-05-24 23:14:25 +08:00
- "_build/meson-logs"
ci: Add scan-build job in a new ‘analysis’ pipeline stage Use Meson’s support for running scan-build (Clang’s static analyser) against the build, so that we get static analysis of each pipeline. Add it in a new pipeline stage, after code coverage, so that we don’t waste resources on it unless the unit tests pass — a static analysis build takes perhaps 10× as long as a normal GCC build. https://mesonbuild.com/howtox.html#use-clang-static-analyzer Currently, the static analysis results are uploaded as artifacts, but the job will always succeed (regardless of whether there are any bugs found in the analysis). Currently, a large number of reports are outputted by the analyser, which need to be fixed before we can gate the pipeline on it. Furthermore, in order to get scan-build to exit with a non-zero status if any bugs are found, we need to depend on Meson ≥ 0.49.0, which contains the fix https://github.com/mesonbuild/meson/issues/4334, allowing us to add the following to .gitlab-ci.yml: ``` variables: # Exit with a non-zero status if any bugs are found SCANBUILD: "scan-build --status-bugs" ``` Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-27 23:32:39 +00:00
scan-build:
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
extends:
ci: Rename .build template to .build-linux This name is more specific to what the template actually does. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:33:09 +00:00
- .build-linux
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
- .only-schedules
ci: Use variables for docker images
2020-01-13 12:45:00 -05:00
image: $FEDORA_IMAGE
ci: Add scan-build job in a new ‘analysis’ pipeline stage Use Meson’s support for running scan-build (Clang’s static analyser) against the build, so that we get static analysis of each pipeline. Add it in a new pipeline stage, after code coverage, so that we don’t waste resources on it unless the unit tests pass — a static analysis build takes perhaps 10× as long as a normal GCC build. https://mesonbuild.com/howtox.html#use-clang-static-analyzer Currently, the static analysis results are uploaded as artifacts, but the job will always succeed (regardless of whether there are any bugs found in the analysis). Currently, a large number of reports are outputted by the analyser, which need to be fixed before we can gate the pipeline on it. Furthermore, in order to get scan-build to exit with a non-zero status if any bugs are found, we need to depend on Meson ≥ 0.49.0, which contains the fix https://github.com/mesonbuild/meson/issues/4334, allowing us to add the following to .gitlab-ci.yml: ``` variables: # Exit with a non-zero status if any bugs are found SCANBUILD: "scan-build --status-bugs" ``` Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-27 23:32:39 +00:00
stage: analysis
ci: Add DAG attributes Add some basic DAG attributes so that some jobs in the pipeline can run out of stage order to speed things up a little. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:00:57 +01:00
needs: []
ci: Add scan-build job in a new ‘analysis’ pipeline stage Use Meson’s support for running scan-build (Clang’s static analyser) against the build, so that we get static analysis of each pipeline. Add it in a new pipeline stage, after code coverage, so that we don’t waste resources on it unless the unit tests pass — a static analysis build takes perhaps 10× as long as a normal GCC build. https://mesonbuild.com/howtox.html#use-clang-static-analyzer Currently, the static analysis results are uploaded as artifacts, but the job will always succeed (regardless of whether there are any bugs found in the analysis). Currently, a large number of reports are outputted by the analyser, which need to be fixed before we can gate the pipeline on it. Furthermore, in order to get scan-build to exit with a non-zero status if any bugs are found, we need to depend on Meson ≥ 0.49.0, which contains the fix https://github.com/mesonbuild/meson/issues/4334, allowing us to add the following to .gitlab-ci.yml: ``` variables: # Exit with a non-zero status if any bugs are found SCANBUILD: "scan-build --status-bugs" ``` Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-27 23:32:39 +00:00
script:
- meson ${MESON_COMMON_OPTIONS}
--werror
--default-library=both
--prefix=$HOME/glib-installed
ci: Set localstatedir to the system directory on CI machines So the tests can access `/var/lib/dbus/machine-id`. This is not a behaviour change relative to older behaviour on CI. In future, it might make more sense to revert this commit and change the CI scripts so they symlink `/home/user/glib-installed/var/lib/dbus/machine-id` to the system machine ID; or ensure that `/etc/machine-id` exists on all the CI machines. That’s too complicated to do right now though. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-02-24 13:16:57 +00:00
--localstatedir=/var
ci: Add scan-build job in a new ‘analysis’ pipeline stage Use Meson’s support for running scan-build (Clang’s static analyser) against the build, so that we get static analysis of each pipeline. Add it in a new pipeline stage, after code coverage, so that we don’t waste resources on it unless the unit tests pass — a static analysis build takes perhaps 10× as long as a normal GCC build. https://mesonbuild.com/howtox.html#use-clang-static-analyzer Currently, the static analysis results are uploaded as artifacts, but the job will always succeed (regardless of whether there are any bugs found in the analysis). Currently, a large number of reports are outputted by the analyser, which need to be fixed before we can gate the pipeline on it. Furthermore, in order to get scan-build to exit with a non-zero status if any bugs are found, we need to depend on Meson ≥ 0.49.0, which contains the fix https://github.com/mesonbuild/meson/issues/4334, allowing us to add the following to .gitlab-ci.yml: ``` variables: # Exit with a non-zero status if any bugs are found SCANBUILD: "scan-build --status-bugs" ``` Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-27 23:32:39 +00:00
--libdir=lib
-Dsystemtap=true
-Ddtrace=true
-Dinstalled_tests=true
ci: Run scan-build in a different build directory The build artifacts from earlier jobs in the pipeline all use the `_build` directory. When they are copied in to the scan-build job, they are probably marked as read-only. This means that the `meson scan-build` run can’t write to `_build/meson-logs/meson-log.txt` and fails. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-06-12 14:31:42 +01:00
_scan_build
- ninja -C _scan_build scan-build
ci: Add scan-build job in a new ‘analysis’ pipeline stage Use Meson’s support for running scan-build (Clang’s static analyser) against the build, so that we get static analysis of each pipeline. Add it in a new pipeline stage, after code coverage, so that we don’t waste resources on it unless the unit tests pass — a static analysis build takes perhaps 10× as long as a normal GCC build. https://mesonbuild.com/howtox.html#use-clang-static-analyzer Currently, the static analysis results are uploaded as artifacts, but the job will always succeed (regardless of whether there are any bugs found in the analysis). Currently, a large number of reports are outputted by the analyser, which need to be fixed before we can gate the pipeline on it. Furthermore, in order to get scan-build to exit with a non-zero status if any bugs are found, we need to depend on Meson ≥ 0.49.0, which contains the fix https://github.com/mesonbuild/meson/issues/4334, allowing us to add the following to .gitlab-ci.yml: ``` variables: # Exit with a non-zero status if any bugs are found SCANBUILD: "scan-build --status-bugs" ``` Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-27 23:32:39 +00:00
artifacts:
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
when: always
ci: Expire CI artifacts after 1 week The default is 30 days, but we don’t need them around that long. This should free up some disk space on the GitLab/CI runner systems. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-04-06 12:54:54 +01:00
expire_in: 1 week
ci: Add scan-build job in a new ‘analysis’ pipeline stage Use Meson’s support for running scan-build (Clang’s static analyser) against the build, so that we get static analysis of each pipeline. Add it in a new pipeline stage, after code coverage, so that we don’t waste resources on it unless the unit tests pass — a static analysis build takes perhaps 10× as long as a normal GCC build. https://mesonbuild.com/howtox.html#use-clang-static-analyzer Currently, the static analysis results are uploaded as artifacts, but the job will always succeed (regardless of whether there are any bugs found in the analysis). Currently, a large number of reports are outputted by the analyser, which need to be fixed before we can gate the pipeline on it. Furthermore, in order to get scan-build to exit with a non-zero status if any bugs are found, we need to depend on Meson ≥ 0.49.0, which contains the fix https://github.com/mesonbuild/meson/issues/4334, allowing us to add the following to .gitlab-ci.yml: ``` variables: # Exit with a non-zero status if any bugs are found SCANBUILD: "scan-build --status-bugs" ``` Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-27 23:32:39 +00:00
paths:
ci: Run scan-build in a different build directory The build artifacts from earlier jobs in the pipeline all use the `_build` directory. When they are copied in to the scan-build job, they are probably marked as read-only. This means that the `meson scan-build` run can’t write to `_build/meson-logs/meson-log.txt` and fails. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-06-12 14:31:42 +01:00
- "_scan_build/meson-logs/scanbuild"
ci: Add scan-build job in a new ‘analysis’ pipeline stage Use Meson’s support for running scan-build (Clang’s static analyser) against the build, so that we get static analysis of each pipeline. Add it in a new pipeline stage, after code coverage, so that we don’t waste resources on it unless the unit tests pass — a static analysis build takes perhaps 10× as long as a normal GCC build. https://mesonbuild.com/howtox.html#use-clang-static-analyzer Currently, the static analysis results are uploaded as artifacts, but the job will always succeed (regardless of whether there are any bugs found in the analysis). Currently, a large number of reports are outputted by the analyser, which need to be fixed before we can gate the pipeline on it. Furthermore, in order to get scan-build to exit with a non-zero status if any bugs are found, we need to depend on Meson ≥ 0.49.0, which contains the fix https://github.com/mesonbuild/meson/issues/4334, allowing us to add the following to .gitlab-ci.yml: ``` variables: # Exit with a non-zero status if any bugs are found SCANBUILD: "scan-build --status-bugs" ``` Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-27 23:32:39 +00:00
ci: Add scheduled Coverity Scan builds This should run Coverity Scan on GLib on the current schedule (once a week). Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:39:24 +01:00
coverity:
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
extends:
ci: Rename .build template to .build-linux This name is more specific to what the template actually does. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:33:09 +00:00
- .build-linux
ci: Replace .build-only-schedules template with multiple extension `.build` and `.only-schedules` are orthogonal, and I want to use `.only-schedules` together with `.cross-template` in future, which would require creating more cross-product templates. Avoid that by splitting `extends: .build-only-schedules` into ``` extends: - .build - .only-schedules ``` Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 12:30:19 +00:00
- .only-schedules
ci: Add scheduled Coverity Scan builds This should run Coverity Scan on GLib on the current schedule (once a week). Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:39:24 +01:00
image: $COVERITY_IMAGE
stage: analysis
needs: []
variables:
# cov-build doesn’t like GLIB_DEPRECATED_ENUMERATOR
CFLAGS: '-DGLIB_DISABLE_DEPRECATION_WARNINGS'
script:
- meson ${MESON_COMMON_OPTIONS}
--werror
--default-library=both
--prefix=$HOME/glib-installed
ci: Set localstatedir to the system directory on CI machines So the tests can access `/var/lib/dbus/machine-id`. This is not a behaviour change relative to older behaviour on CI. In future, it might make more sense to revert this commit and change the CI scripts so they symlink `/home/user/glib-installed/var/lib/dbus/machine-id` to the system machine ID; or ensure that `/etc/machine-id` exists on all the CI machines. That’s too complicated to do right now though. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-02-24 13:16:57 +00:00
--localstatedir=/var
ci: Add scheduled Coverity Scan builds This should run Coverity Scan on GLib on the current schedule (once a week). Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:39:24 +01:00
--libdir=lib
-Dsystemtap=true
-Ddtrace=true
-Dinstalled_tests=true
_coverity_build
- $HOME/cov-analysis-linux64-*/bin/cov-build --dir cov-int ninja -C _coverity_build
- tar cfz cov-int.tar.gz cov-int
- curl https://scan.coverity.com/builds?project=$COVERITY_SCAN_PROJECT_NAME
--form token=$COVERITY_SCAN_TOKEN --form email=$GITLAB_USER_EMAIL
--form file=@cov-int.tar.gz --form version="$CI_COMMIT_SHA"
--form description="$CI_COMMIT_SHA / $CI_COMMIT_TITLE / $CI_COMMIT_REF_NAME:$CI_PIPELINE_ID"
artifacts:
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
when: always
ci: Expire CI artifacts after 1 week The default is 30 days, but we don’t need them around that long. This should free up some disk space on the GitLab/CI runner systems. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-04-06 12:54:54 +01:00
expire_in: 1 week
ci: Add scheduled Coverity Scan builds This should run Coverity Scan on GLib on the current schedule (once a week). Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-07-27 12:39:24 +01:00
paths:
- "cov-int/build-log.txt"
ci: Add GitLab CI description file We're mostly interested into building and testing everything that gets pushed to the repository — including merge requests. When pushing tags, though, we should assume we're spinning a release, so let's run the dist target, and store the tarball, and the generated documentation while we're at it, as artifacts on GitLab. The Dockerfile for the image used for the build is included in tree, and published on Docker Hub. Using a custom image allows us to avoid the costly "download and install build dependencies" phase, as well as controlling the environment a little bit better. https://bugzilla.gnome.org/show_bug.cgi?id=793635
2018-02-18 14:59:29 +00:00
dist-job:
ci: Use variables for docker images
2020-01-13 12:45:00 -05:00
image: $FEDORA_IMAGE
ci: Add GitLab CI description file We're mostly interested into building and testing everything that gets pushed to the repository — including merge requests. When pushing tags, though, we should assume we're spinning a release, so let's run the dist target, and store the tarball, and the generated documentation while we're at it, as artifacts on GitLab. The Dockerfile for the image used for the build is included in tree, and published on Docker Hub. Using a custom image allows us to avoid the costly "download and install build dependencies" phase, as well as controlling the environment a little bit better. https://bugzilla.gnome.org/show_bug.cgi?id=793635
2018-02-18 14:59:29 +00:00
stage: build
only:
- tags
script:
ci: Setup submodules and subprojects before building on dist Also handle a permission issue.
2022-07-12 19:57:17 +02:00
# Ignore extra git security checks as we don't care in CI.
- git config --global --add safe.directory "${PWD}"
- git submodule update --init
- for m in $(git submodule foreach -q 'echo $path'); do git config --global --add safe.directory "${PWD}/${m}"; done
- meson subprojects download
build: Drop checks and workarounds for older Meson versions Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-05-05 19:24:30 +01:00
- meson ${MESON_COMMON_OPTIONS} --buildtype release -Dgtk_doc=true -Dman=true _build
ci: Add GitLab CI description file We're mostly interested into building and testing everything that gets pushed to the repository — including merge requests. When pushing tags, though, we should assume we're spinning a release, so let's run the dist target, and store the tarball, and the generated documentation while we're at it, as artifacts on GitLab. The Dockerfile for the image used for the build is included in tree, and published on Docker Hub. Using a custom image allows us to avoid the costly "download and install build dependencies" phase, as well as controlling the environment a little bit better. https://bugzilla.gnome.org/show_bug.cgi?id=793635
2018-02-18 14:59:29 +00:00
- cd _build
- ninja dist
ci: Fix dist-job missing gobject/gio documentation This requires meson >= 0.47.0 otherwise building the doc fails: https://github.com/mesonbuild/meson/issues/3379 While at it, no need to to pass --prefix --libdir to meson, other CIs don't have them.
2018-06-18 09:47:39 -04:00
- ninja glib-doc gobject-doc gio-doc
ci: Fix documentation tarball compression Best compress using xz when using .tar.xz suffixes.
2020-04-28 14:36:29 +02:00
- tar -c -J -f "glib-docs-$CI_COMMIT_TAG.tar.xz" -C docs/reference/glib html
- tar -c -J -f "gobject-docs-$CI_COMMIT_TAG.tar.xz" -C docs/reference/gobject html
- tar -c -J -f "gio-docs-$CI_COMMIT_TAG.tar.xz" -C docs/reference/gio html
ci: Add GitLab CI description file We're mostly interested into building and testing everything that gets pushed to the repository — including merge requests. When pushing tags, though, we should assume we're spinning a release, so let's run the dist target, and store the tarball, and the generated documentation while we're at it, as artifacts on GitLab. The Dockerfile for the image used for the build is included in tree, and published on Docker Hub. Using a custom image allows us to avoid the costly "download and install build dependencies" phase, as well as controlling the environment a little bit better. https://bugzilla.gnome.org/show_bug.cgi?id=793635
2018-02-18 14:59:29 +00:00
artifacts:
paths:
ci: Fix paths for dist'ed documentation
2020-04-28 13:28:50 +02:00
- "${CI_PROJECT_DIR}/_build/glib-docs-$CI_COMMIT_TAG.tar.xz"
- "${CI_PROJECT_DIR}/_build/gobject-docs-$CI_COMMIT_TAG.tar.xz"
- "${CI_PROJECT_DIR}/_build/gio-docs-$CI_COMMIT_TAG.tar.xz"
ci: Add GitLab CI description file We're mostly interested into building and testing everything that gets pushed to the repository — including merge requests. When pushing tags, though, we should assume we're spinning a release, so let's run the dist target, and store the tarball, and the generated documentation while we're at it, as artifacts on GitLab. The Dockerfile for the image used for the build is included in tree, and published on Docker Hub. Using a custom image allows us to avoid the costly "download and install build dependencies" phase, as well as controlling the environment a little bit better. https://bugzilla.gnome.org/show_bug.cgi?id=793635
2018-02-18 14:59:29 +00:00
- "${CI_PROJECT_DIR}/_build/meson-dist/glib-*.tar.xz"
ci: Open issues when scheduled pipelines fails It's hard to track failures on scheduled pipelines, so make gitlab open an issue for us if that happens.
2022-10-31 02:46:31 +01:00
issue-bot:
stage: report
image: registry.gitlab.com/gitlab-org/distribution/issue-bot:latest
script: /issue-bot
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE == "schedule"
when: on_failure
Reference in New Issue Copy Permalink