luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-11-14 05:16:18 +01:00
Code Issues Packages Projects Releases Wiki Activity
19308d6c18
glib/.gitlab-ci.yml

813 lines
24 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 15:59:29 +01:00
stages:
ci: Run the style-check pipeline stage first Don’t waste CI resources on compiling things which don’t comply with the style rules. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-11-26 13:17:42 +01:00
- style-check
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 15:59:29 +01:00
- 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-28 00:32:39 +01: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 15:59:29 +01: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:
build: Change default for -Dman-pages from disabled to auto Previously, `-Dman=false` was the default, because the generated man pages were shipped in the distribution tarball already, so the option actually mostly controlled whether to *re*build them. The generated pages are no longer shipped in the tarball (and probably haven’t been since the port to Meson, though I haven’t checked), so it makes sense to change the default to encourage building the man pages if the right tooling (`rst2man`) is available. Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2023-12-21 14:35:18 +01:00
FEDORA_IMAGE: "registry.gitlab.gnome.org/gnome/glib/fedora:v26"
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 13:10:07 +01:00
COVERITY_IMAGE: "registry.gitlab.gnome.org/gnome/glib/coverity:v7"
ci: Build with introspection enabled In most CI builds. (Not all of them, though, so we can also test the build works with it disabled.) This is needed for the upcoming libgirepository tests, as they need some GIR files to test against. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3155
2023-11-28 19:00:35 +01:00
DEBIAN_IMAGE: "registry.gitlab.gnome.org/gnome/glib/debian-stable:v19"
ci: Re-add explicit Meson version to Alpine CI image Alpine 3.19 ships with Meson 1.3.0, which has broken handling of File objects and their paths. This causes (as far as I can tell) un-work-around-able breakage of GLib’s build. See https://github.com/mesonbuild/meson/issues/5273#issuecomment-1851811417 That should be fixed in Meson 1.4.0, but that might not be released for a while. Because we’re here to test GLib, not Meson, let’s pin the Meson version in the Alpine CI image to 1.2.3, which we know works and is reasonably up to date (and is what the other CI images use). Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/3361388 Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2023-12-12 12:02:18 +01:00
ALPINE_IMAGE: "registry.gitlab.gnome.org/gnome/glib/alpine:v3"
ci: Build with introspection enabled In most CI builds. (Not all of them, though, so we can also test the build works with it disabled.) This is needed for the upcoming libgirepository tests, as they need some GIR files to test against. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3155
2023-11-28 19:00:35 +01:00
MINGW_IMAGE: "registry.gitlab.gnome.org/gnome/glib/mingw:v15"
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 20:31:55 +02: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 20:24:30 +02: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: Don’t run pipeline after merging a MR MRs are already tested in CI before merge, so it’s redundant and a waste of resources to test them again after merge. In the rare case where something breaks post-merge (perhaps because several MRs have been tested individually and merged, but interact with each other badly), that’ll be caught in the weekly scheduled CI run. YAML inspiration from https://stackoverflow.com/questions/63893431/gitlab-run-a-pipeline-job-when-a-merge-request-is-merged Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-05-15 17:58:58 +02:00
# Default CI job setup; contrast with `.only-origin`.
#
fix: about libproc.h and PROC_PIDLISTFD_SIZE
2023-11-06 15:46:52 +01:00
# Don’t execute the pipeline when a merge request is merged into `origin/main`,
# as it will have already been tested
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 12:38:25 +01: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 12:06:32 +01:00
only:
- branches
except:
ci: Don’t run pipeline after merging a MR MRs are already tested in CI before merge, so it’s redundant and a waste of resources to test them again after merge. In the rare case where something breaks post-merge (perhaps because several MRs have been tested individually and merged, but interact with each other badly), that’ll be caught in the weekly scheduled CI run. YAML inspiration from https://stackoverflow.com/questions/63893431/gitlab-run-a-pipeline-job-when-a-merge-request-is-merged Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-05-15 17:58:58 +02:00
refs:
- tags
variables:
fix: about libproc.h and PROC_PIDLISTFD_SIZE
2023-11-06 15:46:52 +01:00
- $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PROJECT_NAMESPACE == "GNOME"
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 12:06:32 +01:00
ci: Run the fedora CI job on merges as well as branches Since it now has to build the docs (and code coverage) for `main`, that needs to happen after branches are merged. Other jobs remain not-run on merges. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2023-12-12 15:59:02 +01:00
# As above, but does get executed on merge into `origin/main`. For use with
# updating code coverage results and docs builds.
.only-default-and-merges:
only:
- branches
except:
refs:
- 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 13:44:45 +01: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 12:54:58 +02: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 13:30:19 +01: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 12:54:58 +02: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 13:30:19 +01:00
except:
- tags
ci: Add ability to run manually some specific jobs In some merge requests there are bits (such as memory leaks) that we may want to test before merging and that the schedules will run them. As per this add a rule to make them manual, and apply it to some jobs.
2024-01-23 19:18:54 +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.
# But for specific merge requests, one may still want to run them, so make
# possible to run them manually.
.only-schedules-or-manual:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: never
# As per rule before, the following rules will only apply to non MR events
- if: $CI_PIPELINE_SOURCE == "schedule"
when: always
- if: $CI_PIPELINE_SOURCE != "schedule"
when: manual
allow_failure: true
ci: Run docs and coverity builds only on schedules in default branch Also allow running them manually if required, but this still needs to be done from a GNOME/glib:main pipeline.
2024-01-25 17:07:46 +01:00
# Some jobs should be runnable only on schedules and when triggered by a branch
# in the origin repository, but without
.only-schedules-or-manual-in-default-branch:
rules:
- if: $CI_PROJECT_PATH != "GNOME/glib" || $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
when: never
# As per rule before, the following rules will apply only to GNOME/glib:main
- if: $CI_PIPELINE_SOURCE == "schedule"
when: always
- if: $CI_PIPELINE_SOURCE != "schedule"
when: manual
allow_failure: true
ci: Allow to run jobs that only run in origin repos manually
2024-01-25 16:45:25 +01:00
# Some jobs run on CI runners don’t have much available resource.
# Limit those jobs to only ones on the origin repository (GNOME/glib),
# rather than people’s forks or if ran manually.
.only-origin-or-manual:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: never
- if: $CI_PIPELINE_SOURCE == "schedule"
when: never
- if: $CI_PROJECT_NAMESPACE == "GNOME"
when: always
- if: $CI_PROJECT_NAMESPACE != "GNOME"
when: manual
allow_failure: true
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 13:33:09 +01: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 13:30:19 +01: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 12:54:58 +02:00
ci: Manually fetch submodules for style-check CI jobs This works around GitLab issue https://gitlab.com/gitlab-org/gitlab/-/issues/391756, which manifests as the error message: ``` Updating/initializing submodules... Submodule 'subprojects/gvdb' (https://gitlab-ci-token:[MASKED]@gitlab.gnome.org/GNOME/gvdb.git) registered for path 'subprojects/gvdb' Synchronizing submodule url for 'subprojects/gvdb' fatal: not a git repository: subprojects/gvdb/../../.git/modules/subprojects/gvdb ``` on between 1/10 to 1/2 CI runs. See the GitLab issue for a writeup. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-07-05 09:03:09 +02:00
# FIXME: Work around https://gitlab.com/gitlab-org/gitlab/-/issues/391756
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
.with-git:
ci: Manually fetch submodules for style-check CI jobs This works around GitLab issue https://gitlab.com/gitlab-org/gitlab/-/issues/391756, which manifests as the error message: ``` Updating/initializing submodules... Submodule 'subprojects/gvdb' (https://gitlab-ci-token:[MASKED]@gitlab.gnome.org/GNOME/gvdb.git) registered for path 'subprojects/gvdb' Synchronizing submodule url for 'subprojects/gvdb' fatal: not a git repository: subprojects/gvdb/../../.git/modules/subprojects/gvdb ``` on between 1/10 to 1/2 CI runs. See the GitLab issue for a writeup. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-07-05 09:03:09 +02:00
before_script:
- rm -rf subprojects/gvdb
ci: Add an additional git config to avoid permissions warnings And tidy up the existing one for consistency. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-10-11 18:38:04 +02:00
- git config --global --add safe.directory "${PWD}"
ci: Manually fetch submodules for style-check CI jobs This works around GitLab issue https://gitlab.com/gitlab-org/gitlab/-/issues/391756, which manifests as the error message: ``` Updating/initializing submodules... Submodule 'subprojects/gvdb' (https://gitlab-ci-token:[MASKED]@gitlab.gnome.org/GNOME/gvdb.git) registered for path 'subprojects/gvdb' Synchronizing submodule url for 'subprojects/gvdb' fatal: not a git repository: subprojects/gvdb/../../.git/modules/subprojects/gvdb ``` on between 1/10 to 1/2 CI runs. See the GitLab issue for a writeup. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-07-05 09:03:09 +02:00
- git submodule update --init --depth 1
variables:
GIT_SUBMODULE_STRATEGY: "none"
GIT_SUBMODULE_DEPTH: 1
style-check-advisory:
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
extends:
- .only-default
- .with-git
add 2 new stages: sh-check (which run shellcheck) and py-check (which run black and flake8) The debian docker have been modified to install these tools. Closes #2046 Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
2020-11-10 09:53:00 +01:00
image: $DEBIAN_IMAGE
stage: style-check
allow_failure: true
script:
CI: Run all style/lint checks before failing Even if we get warnings from the first lint check, we probably want to see the warnings from later lint checks too, to reduce the number of round-trips. Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:00:45 +01:00
- failed=
- .gitlab-ci/run-style-check-diff.sh || failed=1
- .gitlab-ci/run-check-todos.sh || failed=1
- test -z "$failed"
ci: Move shellcheck/black/flake8 checks to a new CI job which can fail We were regressing on Python style too often. Since Python code style is a lot easier to enforce than C code style, split it (and the shellcheck checks) out from `style-check-diff` into a new CI job which is allowed to fail the pipeline. Only trigger it when .sh or .py files have changed, which should reduce resource consumption. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-10-27 10:30:06 +02:00
sh-and-py-check:
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
extends:
- .only-default
- .with-git
ci: Move shellcheck/black/flake8 checks to a new CI job which can fail We were regressing on Python style too often. Since Python code style is a lot easier to enforce than C code style, split it (and the shellcheck checks) out from `style-check-diff` into a new CI job which is allowed to fail the pipeline. Only trigger it when .sh or .py files have changed, which should reduce resource consumption. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-10-27 10:30:06 +02:00
image: $DEBIAN_IMAGE
stage: style-check
allow_failure: false
script:
CI: Run all style/lint checks before failing Even if we get warnings from the first lint check, we probably want to see the warnings from later lint checks too, to reduce the number of round-trips. Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:00:45 +01:00
- failed=
- tests/shellcheck.sh || failed=1
- tests/black.sh || failed=1
- tests/flake8.sh || failed=1
- test -z "$failed"
Incorporate some lint checks into `meson test` This will make it easier and more obvious for developers to run them locally: I'm sure I'm not the only developer who had assumed that `.gitlab-ci/` is private to the CI environment and inappropriate (or perhaps even destructive) to run on a developer/user system. The lint checks are automatically skipped (with TAP SKIP syntax) if we are not in a git checkout, or if git or the lint tool is missing. They can also be disabled explicitly with `meson test --no-suite=lint`, which downstream distributions will probably want to do. By default, most lint checks are reported as an "expected failure" (with TAP TODO syntax) rather than a hard failure, because they do not indicate a functional problem with GLib and there is a tendency for lint tools to introduce additional checks or become more strict over time. Developers can override this by configuring with `-Dwerror=true` (which also makes compiler warnings into fatal errors), or by running the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`. One exception to this is tests/check-missing-install-tag.py, which is checking a functionally significant feature of our build system, and seems like it is unlikely to have false positives: if that one fails, it is reported as a hard failure. run-style-check-diff.sh and run-check-todos.sh are not currently given this treatment, because they require search-common-ancestor.sh, which uses Gitlab-CI-specific information to find out which commits are in-scope for checking. Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 13:16:22 +01:00
variables:
LINT_WARNINGS_ARE_ERRORS: '1'
ci: Move shellcheck/black/flake8 checks to a new CI job which can fail We were regressing on Python style too often. Since Python code style is a lot easier to enforce than C code style, split it (and the shellcheck checks) out from `style-check-diff` into a new CI job which is allowed to fail the pipeline. Only trigger it when .sh or .py files have changed, which should reduce resource consumption. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-10-27 10:30:06 +02:00
only:
changes:
- "**/*.py"
- "**/*.sh"
ci: Add checks for banned keywords in merge requests Using the same approach as we have for code style checks (the `style-check-diff` CI job), check the diff for any banned keywords like ‘TODO’, and also check the commit messages. The keyword ‘TODO’ is often used by developers to indicate a part of a commit which needs further work, and hence which shouldn’t yet be merged. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #1551
2019-04-25 12:23:26 +02:00
ci: Add a CI check for REUSE-compliant licensing/copyright headers This doesn’t enforce licensing/copyright headers to be present on all files, but does check that at least a minimum number of files are correct. This should help avoid new files being added without appropriate licensing information in future. The baseline is set at what `reuse lint` outputs for me at the moment. See https://reuse.software/tutorial/#step-2 for information about how to add REUSE-compliant licensing/copyright to files. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #1415
2022-11-02 16:20:09 +01:00
style-check-mandatory:
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
extends:
- .only-default
- .with-git
ci: Add a CI check for REUSE-compliant licensing/copyright headers This doesn’t enforce licensing/copyright headers to be present on all files, but does check that at least a minimum number of files are correct. This should help avoid new files being added without appropriate licensing information in future. The baseline is set at what `reuse lint` outputs for me at the moment. See https://reuse.software/tutorial/#step-2 for information about how to add REUSE-compliant licensing/copyright to files. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #1415
2022-11-02 16:20:09 +01:00
image: $DEBIAN_IMAGE
stage: style-check
allow_failure: false
script:
Incorporate some lint checks into `meson test` This will make it easier and more obvious for developers to run them locally: I'm sure I'm not the only developer who had assumed that `.gitlab-ci/` is private to the CI environment and inappropriate (or perhaps even destructive) to run on a developer/user system. The lint checks are automatically skipped (with TAP SKIP syntax) if we are not in a git checkout, or if git or the lint tool is missing. They can also be disabled explicitly with `meson test --no-suite=lint`, which downstream distributions will probably want to do. By default, most lint checks are reported as an "expected failure" (with TAP TODO syntax) rather than a hard failure, because they do not indicate a functional problem with GLib and there is a tendency for lint tools to introduce additional checks or become more strict over time. Developers can override this by configuring with `-Dwerror=true` (which also makes compiler warnings into fatal errors), or by running the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`. One exception to this is tests/check-missing-install-tag.py, which is checking a functionally significant feature of our build system, and seems like it is unlikely to have false positives: if that one fails, it is reported as a hard failure. run-style-check-diff.sh and run-check-todos.sh are not currently given this treatment, because they require search-common-ancestor.sh, which uses Gitlab-CI-specific information to find out which commits are in-scope for checking. Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 13:16:22 +01:00
- tests/reuse.sh
variables:
LINT_WARNINGS_ARE_ERRORS: '1'
ci: Add a CI check for REUSE-compliant licensing/copyright headers This doesn’t enforce licensing/copyright headers to be present on all files, but does check that at least a minimum number of files are correct. This should help avoid new files being added without appropriate licensing information in future. The baseline is set at what `reuse lint` outputs for me at the moment. See https://reuse.software/tutorial/#step-2 for information about how to add REUSE-compliant licensing/copyright to files. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #1415
2022-11-02 16:20:09 +01:00
ci: Use shorter job names Job names in gitlab pipeline view gets truncated to "fedora-meson-..." for all jobs which is not really useful. All our CIs are using Meson, and the host distro is not relevant when doing cross builds.
2018-06-22 17:08:06 +02:00
fedora-x86_64:
ci: Split .only-default out of .build-linux As with a previous commit, `.only-default` does things which are orthogonal to what `.build-linux` does, so it’s clearer and more extensible for CI jobs to specify both in their top-level `extends` statements, rather than relying on `.build-linux` to pull `.only-default` in. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 13:36:40 +01:00
extends:
- .build-linux
ci: Run the fedora CI job on merges as well as branches Since it now has to build the docs (and code coverage) for `main`, that needs to happen after branches are merged. Other jobs remain not-run on merges. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2023-12-12 15:59:02 +01:00
- .only-default-and-merges
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
- .with-git
ci: Use variables for docker images
2020-01-13 18:45:00 +01: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 15:59:29 +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 13:00:57 +02:00
needs: []
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
variables:
build: Move -Wnonnull flag to meson.build It should be enabled in all builds, not just CI builds. Otherwise developers might miss it locally. This updates commit f11b96f255ee69f7ea5c51a2596f5cf1909a32b9. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-11-18 14:33:20 +01:00
CFLAGS: "-coverage -ftest-coverage -fprofile-arcs"
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 15:59:29 +01:00
script:
meson: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${MESON_COMMON_OPTIONS}
CI: Test static build on installed glib
2018-09-26 16:56:10 +02:00
--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 14:16:57 +01:00
--localstatedir=/var
CI: Test static build on installed glib
2018-09-26 16:56:10 +02:00
--libdir=lib
-Dsystemtap=true
-Ddtrace=true
-Dinstalled_tests=true
build: Rename -Dgtk_doc option to -Ddocumentation Because the documentation is no longer built using gtk-doc. Keep the old option around, but deprecated. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2023-11-29 11:26:37 +01:00
-Ddocumentation=true
ci: Build with introspection enabled In most CI builds. (Not all of them, though, so we can also test the build works with it disabled.) This is needed for the upcoming libgirepository tests, as they need some GIR files to test against. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3155
2023-11-28 19:00:35 +01:00
-Dintrospection=enabled
docs: Port the man pages from DocBook to reStructuredText So they are consistent with the way we’re building man pages in other projects, and because some people are allergic to XML. This changes the build-time dependencies from `xsltproc` to `rst2man`, and also takes the opportunity to change the `-Dman` Meson option from a boolean to a feature (so you should use `-Dman-pages={enabled,disabled}` now, rather than `-Dman={true,false}`). Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2023-12-20 15:04:11 +01:00
-Dman-pages=enabled
CI: Test static build on installed glib
2018-09-26 16:56:10 +02:00
_build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson compile -C _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
- mkdir -p _coverage
build: Move lcovrc file to root so it’s picked up by Meson Move the lcovrc file to the root of the project, so that it’s picked up by Meson when running `ninja coverage` locally. See https://github.com/mesonbuild/meson/issues/4628 This won’t affect the code coverage run on the CI, since that explicitly used the lcovrc file already. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-04-28 12:57:45 +02:00
- lcov --config-file .lcovrc --directory _build --capture --initial --output-file "_coverage/${CI_JOB_NAME}-baseline.lcov"
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 21:53:11 +02:00
- .gitlab-ci/run-tests.sh
build: Move lcovrc file to root so it’s picked up by Meson Move the lcovrc file to the root of the project, so that it’s picked up by Meson when running `ninja coverage` locally. See https://github.com/mesonbuild/meson/issues/4628 This won’t affect the code coverage run on the CI, since that explicitly used the lcovrc file already. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-04-28 12:57:45 +02:00
- lcov --config-file .lcovrc --directory _build --capture --output-file "_coverage/${CI_JOB_NAME}.lcov"
ci: Build docs artifacts for deployment to docs.gtk.org The actual deployment will be done by https://gitlab.gnome.org/GNOME/gtk/-/blob/docs-gtk-org/; it pulls the most recent artifact zip from glib.git. This ensures that only one project/job/branch has push access to the website. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2023-12-12 15:57:57 +01:00
# Copy the built documentation to an artifact directory. The build for docs.gtk.org
# can then pull it from there — see https://gitlab.gnome.org/GNOME/gtk/-/blob/docs-gtk-org/README.md
- mkdir -p _reference/
- mv _build/docs/reference/glib/glib/ _reference/glib/
ci: Build and tar the platform specific documentation Enable the msys2-mingw32 CI job for merges, just like the fedora-x86_64 job is. The pair of them can then build the platform specific GIR and documentation files. The `download-reference.sh` script in the `docs-gtk-org` branch of GTK can then download the docs as an artifact from the latest GLib build of `main`, and publish them on docs.gtk.org, as is currently done for the platform agnostic documentation. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 17:34:36 +01:00
- mv _build/docs/reference/glib/glib-unix/ _reference/glib-unix/
ci: Build docs artifacts for deployment to docs.gtk.org The actual deployment will be done by https://gitlab.gnome.org/GNOME/gtk/-/blob/docs-gtk-org/; it pulls the most recent artifact zip from glib.git. This ensures that only one project/job/branch has push access to the website. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2023-12-12 15:57:57 +01:00
- mv _build/docs/reference/gmodule/gmodule/ _reference/gmodule/
- mv _build/docs/reference/gobject/gobject/ _reference/gobject/
- mv _build/docs/reference/gio/gio/ _reference/gio/
ci: Build and tar the platform specific documentation Enable the msys2-mingw32 CI job for merges, just like the fedora-x86_64 job is. The pair of them can then build the platform specific GIR and documentation files. The `download-reference.sh` script in the `docs-gtk-org` branch of GTK can then download the docs as an artifact from the latest GLib build of `main`, and publish them on docs.gtk.org, as is currently done for the platform agnostic documentation. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 17:34:36 +01:00
- mv _build/docs/reference/gio/gio-unix/ _reference/gio-unix/
ci: Build and tar libgirepository documentation Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-02-12 18:01:15 +01:00
- mv _build/docs/reference/girepository/girepository/ _reference/girepository/
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 15:59:29 +01: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 21:53:11 +02: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: Clarify artifact naming Put the job name and commit identifier in the artifact names. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-05-29 11:54:29 +02:00
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
ci: Always export artifacts from Fedora build The default `when: on_success` means no artifacts are exported when the tests fail, which is precisely when we want to see the artifacts. Always export them, and rely on GitLab to garbage collect them as appropriate (typically after 30 days, I think). Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-05-29 11:53:41 +02:00
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 13:54:54 +02:00
expire_in: 1 week
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 15:59:29 +01:00
paths:
ci: Include config.h and glibconfig.h in CI output artifacts It’s useful to see what configuration was generated. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-08-29 12:16:58 +02:00
- "_build/config.h"
- "_build/glib/glibconfig.h"
ci: Be consistent on artifact naming
2018-06-05 20:01:53 +02:00
- "_build/meson-logs"
- "_coverage"
ci: Build docs artifacts for deployment to docs.gtk.org The actual deployment will be done by https://gitlab.gnome.org/GNOME/gtk/-/blob/docs-gtk-org/; it pulls the most recent artifact zip from glib.git. This ensures that only one project/job/branch has push access to the website. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2023-12-12 15:57:57 +01:00
- "_reference"
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 15:59:29 +01:00
ci: Add a debian-stable job So we can test ancient toolchains.
2019-04-30 15:01:56 +02:00
debian-stable-x86_64:
ci: Split .only-default out of .build-linux As with a previous commit, `.only-default` does things which are orthogonal to what `.build-linux` does, so it’s clearer and more extensible for CI jobs to specify both in their top-level `extends` statements, rather than relying on `.build-linux` to pull `.only-default` in. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 13:36:40 +01:00
extends:
- .build-linux
- .only-default
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
- .with-git
ci: Use variables for docker images
2020-01-13 18:45:00 +01:00
image: $DEBIAN_IMAGE
ci: Add a debian-stable job So we can test ancient toolchains.
2019-04-30 15:01:56 +02: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 13:00:57 +02:00
needs: []
ci: Add a debian-stable job So we can test ancient toolchains.
2019-04-30 15:01:56 +02:00
script:
meson: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${MESON_COMMON_OPTIONS}
ci: Add a debian-stable job So we can test ancient toolchains.
2019-04-30 15:01:56 +02:00
--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 14:16:57 +01:00
--localstatedir=/var
ci: Add a debian-stable job So we can test ancient toolchains.
2019-04-30 15:01:56 +02:00
--libdir=lib
-Dsystemtap=true
-Ddtrace=true
_build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson compile -C _build
ci: Add a debian-stable job So we can test ancient toolchains.
2019-04-30 15:01:56 +02:00
- .gitlab-ci/run-tests.sh
artifacts:
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 debian-stable job So we can test ancient toolchains.
2019-04-30 15:01:56 +02: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 13:54:54 +02:00
expire_in: 1 week
ci: Add a debian-stable job So we can test ancient toolchains.
2019-04-30 15:01:56 +02:00
paths:
- "_build/config.h"
- "_build/glib/glibconfig.h"
- "_build/meson-logs"
Initial test of Hurd CI - (run_tests.sh status ignored)
2023-10-19 01:33:04 +02:00
hurd-i386:
extends:
ci: Add ability to run manually some specific jobs In some merge requests there are bits (such as memory leaks) that we may want to test before merging and that the schedules will run them. As per this add a rule to make them manual, and apply it to some jobs.
2024-01-23 19:18:54 +01:00
- .only-schedules-or-manual
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
- .with-git
Initial test of Hurd CI - (run_tests.sh status ignored)
2023-10-19 01:33:04 +02:00
stage: build
tags:
- hurd
needs: []
script:
ci: Temporarily disable --fatal-meson-warnings on Hurd CI For the same reasons as in commit 71061fdcb33b8c26f5f8467c, but in this case we can’t downgrade the version of Meson on the CI runner, so just tell it to shut up instead. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3238
2024-01-30 10:56:17 +01:00
# FIXME: We can’t use ${MESON_COMMON_OPTIONS} here because the Hurd runner
# has Meson 1.3 installed. See the comment below about the same problem on
# FreeBSD.
- meson setup
--buildtype debug
--wrap-mode=nodownload
Initial test of Hurd CI - (run_tests.sh status ignored)
2023-10-19 01:33:04 +02:00
--werror
--default-library=both
--prefix=$HOME/glib-installed
--localstatedir=/var
--libdir=lib
_build
- meson compile -C _build
- .gitlab-ci/run-tests.sh
artifacts:
reports:
junit:
- _build/meson-logs/testlog.junit.xml
- _build/meson-logs/testlog-*.junit.xml
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
when: always
expire_in: 1 week
paths:
- "_build/config.h"
- "_build/glib/glibconfig.h"
- "_build/meson-logs"
ci: Make the Alpine CI name more consistent The image uses `alpine:latest`, so let’s drop the ‘stable’ moniker. This also makes the container registry ID match the Dockerfile name. Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2023-11-28 12:51:30 +01:00
muslc-alpine-x86_64:
ci: add muslc CI
2023-08-10 20:10:01 +02:00
extends:
- .build-linux
ci: Add ability to run manually some specific jobs In some merge requests there are bits (such as memory leaks) that we may want to test before merging and that the schedules will run them. As per this add a rule to make them manual, and apply it to some jobs.
2024-01-23 19:18:54 +01:00
- .only-schedules-or-manual
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
- .with-git
ci: add muslc CI
2023-08-10 20:10:01 +02:00
image: $ALPINE_IMAGE
stage: build
needs: []
script:
- meson setup ${MESON_COMMON_OPTIONS}
--werror
--default-library=both
--prefix=$HOME/glib-installed
--localstatedir=/var
--libdir=lib
-Dsystemtap=true
_build
- meson compile -C _build
- .gitlab-ci/run-tests.sh
artifacts:
reports:
junit:
- _build/meson-logs/testlog.junit.xml
- _build/meson-logs/testlog-*.junit.xml
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
when: always
expire_in: 1 week
paths:
- "_build/config.h"
- "_build/glib/glibconfig.h"
- "_build/meson-logs"
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 13:30:19 +01: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 13:33:09 +01:00
- .build-linux
ci: Add ability to run manually some specific jobs In some merge requests there are bits (such as memory leaks) that we may want to test before merging and that the schedules will run them. As per this add a rule to make them manual, and apply it to some jobs.
2024-01-23 19:18:54 +01:00
- .only-schedules-or-manual
ci: Use variables for docker images
2020-01-13 18:45:00 +01: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 13:00:57 +02: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: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${MESON_COMMON_OPTIONS}
ci: Run installed-tests on Fedora Run installed-tests on a Fedora system.
2019-11-15 11:59:00 +01:00
--werror
--prefix=/usr --libdir=/usr/lib64
-Dinstalled_tests=true
-Ddefault_library=both
-Ddtrace=false
_build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson compile -C _build
- sudo meson install -C _build
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 07:38:20 +01: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 12:06:00 +01: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 13:54:54 +02: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 12:02:24 +01: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 13:30:19 +01: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 13:33:09 +01:00
- .build-linux
ci: Add ability to run manually some specific jobs In some merge requests there are bits (such as memory leaks) that we may want to test before merging and that the schedules will run them. As per this add a rule to make them manual, and apply it to some jobs.
2024-01-23 19:18:54 +01:00
- .only-schedules-or-manual
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
- .with-git
ci: Use variables for docker images
2020-01-13 18:45:00 +01: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 12:02:24 +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 13:00:57 +02:00
needs: []
ci: Run the thorough test setup on a weekly schedule Merge it with the `G_DISABLE_ASSERT` test run, to avoid tying up another test runner for no particular benefit. By running the thorough tests regularly, we’ll hopefully avoid them atrophying again (see the previous few commits full of fixes to them). Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-01-18 17:55:40 +01:00
variables:
MESON_TEST_TIMEOUT_MULTIPLIER: 15
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 12:02:24 +01:00
script:
meson: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${MESON_COMMON_OPTIONS}
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 12:02:24 +01:00
--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 21:14:31 +02:00
-Dglib_assert=false
ci: Build with introspection enabled In most CI builds. (Not all of them, though, so we can also test the build works with it disabled.) This is needed for the upcoming libgirepository tests, as they need some GIR files to test against. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3155
2023-11-28 19:00:35 +01:00
-Dintrospection=enabled
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 12:02:24 +01:00
_build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson compile -C _build
ci: Run the thorough test setup on a weekly schedule Merge it with the `G_DISABLE_ASSERT` test run, to avoid tying up another test runner for no particular benefit. By running the thorough tests regularly, we’ll hopefully avoid them atrophying again (see the previous few commits full of fixes to them). Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-01-18 17:55:40 +01:00
# Also take the opportunity to run the thorough tests (which are slow)
- bash -x ./.gitlab-ci/run-tests.sh --setup thorough
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 12:02:24 +01: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 21:53:11 +02: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 12:02:24 +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 13:54:54 +02: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 12:02:24 +01: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 18:23:09 +02: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 13:30:19 +01: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 13:33:09 +01:00
- .build-linux
ci: Add ability to run manually some specific jobs In some merge requests there are bits (such as memory leaks) that we may want to test before merging and that the schedules will run them. As per this add a rule to make them manual, and apply it to some jobs.
2024-01-23 19:18:54 +01:00
- .only-schedules-or-manual
CI: Extend submodule workaround to most jobs that run the test suite Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 14:46:11 +01:00
- .with-git
ci: Use variables for docker images
2020-01-13 18:45:00 +01: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 18:23:09 +02: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 13:00:57 +02: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 18:23:09 +02: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 18:23:09 +02:00
script:
meson: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${MESON_COMMON_OPTIONS}
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 18:23:09 +02:00
--werror
-Dsystemtap=true
-Ddtrace=true
-Dinstalled_tests=true
ci: Build with introspection enabled In most CI builds. (Not all of them, though, so we can also test the build works with it disabled.) This is needed for the upcoming libgirepository tests, as they need some GIR files to test against. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3155
2023-11-28 19:00:35 +01:00
-Dintrospection=enabled
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 18:23:09 +02:00
_build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson compile -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 15:48:34 +02: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 18:23:09 +02: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 12:01:04 +02: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 18:23:09 +02: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 18:23:09 +02: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 13:54:54 +02: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 18:23:09 +02: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 13:34:20 +01: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 13:33:09 +01: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 06:14:56 +02: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 13:00:57 +02: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 06:14:56 +02:00
artifacts:
ci: Be consistent on artifact naming
2018-06-05 20:01:53 +02: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 13:54:54 +02: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 06:14:56 +02:00
paths:
ci: Be consistent on artifact naming
2018-06-05 20:01:53 +02: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 06:14:56 +02:00
ci: Update to latest Android NDK Move the NDK in the common Fedora image, better have 1 bigger image that gets cached into runners. It is also less images to maintain. Fixes: #2605
2022-04-26 16:50:36 +02:00
cross-android_arm64:
ci: Split .only-default out of .build-linux As with a previous commit, `.only-default` does things which are orthogonal to what `.build-linux` does, so it’s clearer and more extensible for CI jobs to specify both in their top-level `extends` statements, rather than relying on `.build-linux` to pull `.only-default` in. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 13:36:40 +01:00
extends:
- .cross-build-linux
- .only-default
ci: Update to latest Android NDK Move the NDK in the common Fedora image, better have 1 bigger image that gets cached into runners. It is also less images to maintain. Fixes: #2605
2022-04-26 16:50:36 +02:00
image: $FEDORA_IMAGE
ci: Add latest Android API level 28 - Split the download part into a separate script to so docker keeps that step in cache and avoid redownloading it. - With API level >= 28 libiconv is not needed anymore because it's part of Android's libc. - Generate standalone toolchains to reduce the docker image size. It's also easier because it doesn't need to pass sysroot args. - Use clang compiler because gcc is deprecated in this Android NDK and will be removed in the next release.
2018-06-26 19:18:29 +02:00
script:
# FIXME: add --werror
meson: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${MESON_COMMON_OPTIONS} --cross-file=.gitlab-ci/cross_file_android_arm64_31.txt _build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson compile -C _build
ci: Add latest Android API level 28 - Split the download part into a separate script to so docker keeps that step in cache and avoid redownloading it. - With API level >= 28 libiconv is not needed anymore because it's part of Android's libc. - Generate standalone toolchains to reduce the docker image size. It's also easier because it doesn't need to pass sysroot args. - Use clang compiler because gcc is deprecated in this Android NDK and will be removed in the next release.
2018-06-26 19:18:29 +02:00
ci: Use shorter job names Job names in gitlab pipeline view gets truncated to "fedora-meson-..." for all jobs which is not really useful. All our CIs are using Meson, and the host distro is not relevant when doing cross builds.
2018-06-22 17:08:06 +02:00
cross-mingw64:
ci: Split .only-default out of .build-linux As with a previous commit, `.only-default` does things which are orthogonal to what `.build-linux` does, so it’s clearer and more extensible for CI jobs to specify both in their top-level `extends` statements, rather than relying on `.build-linux` to pull `.only-default` in. This introduces no functional changes. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-20 13:36:40 +01:00
extends:
- .cross-build-linux
- .only-default
ci: Use variables for docker images
2020-01-13 18:45:00 +01:00
image: $MINGW_IMAGE
Enable Python UTF-8 mode for Windows CI jobs It will become the default in Python 3.15 and makes things more consistent across Unix and Windows platforms. Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2915
2023-02-15 19:23:04 +01:00
variables:
PYTHONUTF8: "1"
Add mingw64 cross build CI Fixes #1387.
2018-05-20 21:17:48 +02:00
script:
# FIXME: Add --werror
meson: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${MESON_COMMON_OPTIONS} --cross-file=/opt/cross_file_mingw64.txt _build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson compile -C _build
Provide built DLLs as Gitlab-CI artifacts
2021-09-20 14:13:36 +02:00
artifacts:
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
Provide built DLLs as Gitlab-CI artifacts
2021-09-20 14:13:36 +02:00
name: "glib-${env:CI_JOB_NAME}-${env: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 13:54:54 +02:00
expire_in: 1 week
Provide built DLLs as Gitlab-CI artifacts
2021-09-20 14:13:36 +02:00
paths:
- _build/meson-logs
- _build/glib/libglib-2.0-0.dll
- _build/gio/libgio-2.0-0.dll
- _build/gmodule/libgmodule-2.0-0.dll
- _build/gthread/libgthread-2.0-0.dll
- _build/gobject/libgobject-2.0-0.dll
Add mingw64 cross build CI Fixes #1387.
2018-05-20 21:17:48 +02: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
msys2-mingw32:
ci: Build and tar the platform specific documentation Enable the msys2-mingw32 CI job for merges, just like the fedora-x86_64 job is. The pair of them can then build the platform specific GIR and documentation files. The `download-reference.sh` script in the `docs-gtk-org` branch of GTK can then download the docs as an artifact from the latest GLib build of `main`, and publish them on docs.gtk.org, as is currently done for the platform agnostic documentation. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 17:34:36 +01:00
extends: .only-default-and-merges
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
stage: build
tags:
CI: Switch to new Windows runners gitlab will drop cmd.exe support with GitLab 13 so I took the opportunity to add new runners with Windows 2016 and powershell as default. These runners are tagged with win32-ps instead of win32. The old runners will be switched off in the coming weeks. The main difference is that all commands and env expansions use powershell and Windows 2016 instead of 2012r2.
2020-04-29 08:44:43 +02:00
- win32-ps
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 13:00:57 +02:00
needs: []
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
variables:
MSYSTEM: "MINGW32"
CHERE_INVOKING: "yes"
ci: Set CFLAGS on msys2-mingw32 in yaml file as it happens for other jobs Be consistent, and based on this also perform the lcov job or not
2022-10-29 04:12:21 +02:00
CFLAGS: -coverage -ftest-coverage -fprofile-arcs
Enable Python UTF-8 mode for Windows CI jobs It will become the default in Python 3.15 and makes things more consistent across Unix and Windows platforms. Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2915
2023-02-15 19:23:04 +01:00
PYTHONUTF8: "1"
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
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu --ask 20
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 15:35:54 +01:00
- C:\msys64\usr\bin\bash .gitlab-ci/show-execution-environment.sh
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
- C:\msys64\usr\bin\bash -lc "bash -x ./.gitlab-ci/test-msys2.sh"
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
artifacts:
ci: Run test coverage for MSYS2 job
2019-04-06 16:22:04 +02: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: Switch to new Windows runners gitlab will drop cmd.exe support with GitLab 13 so I took the opportunity to add new runners with Windows 2016 and powershell as default. These runners are tagged with win32-ps instead of win32. The old runners will be switched off in the coming weeks. The main difference is that all commands and env expansions use powershell and Windows 2016 instead of 2012r2.
2020-04-29 08:44:43 +02:00
name: "glib-${env:CI_JOB_NAME}-${env:CI_COMMIT_REF_NAME}"
ci: Export meson-logs from msys2-mingw32 build as artifacts This means that compilation and test failures will leave logs on the CI machines which we can use to debug the failures. Always export the artifacts. The default `when: on_success` is appropriate for now, but won’t be in future when the tests actual report their success value correctly. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-05-28 14:11:22 +02:00
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 13:54:54 +02:00
expire_in: 1 week
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
paths:
ci: Export meson-logs from msys2-mingw32 build as artifacts This means that compilation and test failures will leave logs on the CI machines which we can use to debug the failures. Always export the artifacts. The default `when: on_success` is appropriate for now, but won’t be in future when the tests actual report their success value correctly. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-05-28 14:11:22 +02:00
- _build/meson-logs
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: Build and tar the platform specific documentation Enable the msys2-mingw32 CI job for merges, just like the fedora-x86_64 job is. The pair of them can then build the platform specific GIR and documentation files. The `download-reference.sh` script in the `docs-gtk-org` branch of GTK can then download the docs as an artifact from the latest GLib build of `main`, and publish them on docs.gtk.org, as is currently done for the platform agnostic documentation. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 17:34:36 +01:00
- _reference/
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
ci: Add an msys2-clang64 job to run only on schedules It has enough particularities to require a job to monitor failures
2022-10-29 04:14:29 +02:00
msys2-clang64:
ci: Add ability to run manually some specific jobs In some merge requests there are bits (such as memory leaks) that we may want to test before merging and that the schedules will run them. As per this add a rule to make them manual, and apply it to some jobs.
2024-01-23 19:18:54 +01:00
extends: .only-schedules-or-manual
ci: Add an msys2-clang64 job to run only on schedules It has enough particularities to require a job to monitor failures
2022-10-29 04:14:29 +02:00
stage: build
tags:
- win32-ps
needs: []
variables:
MSYSTEM: "CLANG64"
CHERE_INVOKING: "yes"
Enable Python UTF-8 mode for Windows CI jobs It will become the default in Python 3.15 and makes things more consistent across Unix and Windows platforms. Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2915
2023-02-15 19:23:04 +01:00
PYTHONUTF8: "1"
ci: Add an msys2-clang64 job to run only on schedules It has enough particularities to require a job to monitor failures
2022-10-29 04:14:29 +02:00
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu --ask 20
- C:\msys64\usr\bin\bash .gitlab-ci/show-execution-environment.sh
- C:\msys64\usr\bin\bash -lc "bash -x ./.gitlab-ci/test-msys2.sh"
artifacts:
reports:
junit: "_build/meson-logs/testlog.junit.xml"
name: "glib-${env:CI_JOB_NAME}-${env:CI_COMMIT_REF_NAME}"
when: always
expire_in: 1 week
paths:
- _build/meson-logs
ci: Add a VS2017 job Thanks to Xavier Claessens for figuring out what is needed.
2018-05-24 19:18:25 +02:00
vs2017-x64:
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 12:38:25 +01:00
extends: .only-default
ci: Add a VS2017 job Thanks to Xavier Claessens for figuring out what is needed.
2018-05-24 19:18:25 +02:00
stage: build
tags:
CI: Switch to new Windows runners gitlab will drop cmd.exe support with GitLab 13 so I took the opportunity to add new runners with Windows 2016 and powershell as default. These runners are tagged with win32-ps instead of win32. The old runners will be switched off in the coming weeks. The main difference is that all commands and env expansions use powershell and Windows 2016 instead of 2012r2.
2020-04-29 08:44:43 +02:00
- win32-ps
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 13:00:57 +02:00
needs: []
Enable Python UTF-8 mode for Windows CI jobs It will become the default in Python 3.15 and makes things more consistent across Unix and Windows platforms. Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2915
2023-02-15 19:23:04 +01:00
variables:
PYTHONUTF8: "1"
ci: Add a VS2017 job Thanks to Xavier Claessens for figuring out what is needed.
2018-05-24 19:18:25 +02:00
script:
Add Windows native static build using msvc to CI
2022-01-14 17:01:16 +01:00
# FIXME: These should use --wrap-mode=nodownload but the Windows CI machines
# aren’t currently set up for that.
ci: Explicitly specify Python installation path on Windows Meson used to try and guess at the Python path. While this worked fine for GLib before, it probably didn’t work 100% for other projects, so Meson have made it an explicit option. Set that option with the Python path used on the Windows CI machines. This fixes a Meson warning with Meson >0.60. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-05-06 14:46:53 +02:00
- .gitlab-ci/test-msvc.bat ${MESON_COMMON_OPTIONS}
--wrap-mode=default
--python.platlibdir=C:\Python37\site-packages
--python.purelibdir=C:\Python37\site-packages
ci: Add a VS2017 job Thanks to Xavier Claessens for figuring out what is needed.
2018-05-24 19:18:25 +02:00
artifacts:
CI: Run test coverage for Visual Studio builds Ensure that we do run it and upload the results.
2019-04-08 10:51:47 +02: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: Switch to new Windows runners gitlab will drop cmd.exe support with GitLab 13 so I took the opportunity to add new runners with Windows 2016 and powershell as default. These runners are tagged with win32-ps instead of win32. The old runners will be switched off in the coming weeks. The main difference is that all commands and env expansions use powershell and Windows 2016 instead of 2012r2.
2020-04-29 08:44:43 +02:00
name: "glib-${env:CI_JOB_NAME}-${env:CI_COMMIT_REF_NAME}"
ci: Add a VS2017 job Thanks to Xavier Claessens for figuring out what is needed.
2018-05-24 19:18:25 +02:00
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 13:54:54 +02:00
expire_in: 1 week
ci: Add a VS2017 job Thanks to Xavier Claessens for figuring out what is needed.
2018-05-24 19:18:25 +02:00
paths:
- _build/meson-logs
Provide built DLLs as Gitlab-CI artifacts
2021-09-20 14:13:36 +02:00
- _build/glib/libglib-2.0-0.dll
- _build/gio/libgio-2.0-0.dll
- _build/gmodule/libgmodule-2.0-0.dll
- _build/gthread/libgthread-2.0-0.dll
- _build/gobject/libgobject-2.0-0.dll
ci: Add a VS2017 job Thanks to Xavier Claessens for figuring out what is needed.
2018-05-24 19:18:25 +02:00
Add Windows native static build using msvc to CI
2022-01-14 17:01:16 +01:00
vs2017-x64-static:
extends: .only-default
stage: build
tags:
- win32-ps
needs: []
Enable Python UTF-8 mode for Windows CI jobs It will become the default in Python 3.15 and makes things more consistent across Unix and Windows platforms. Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2915
2023-02-15 19:23:04 +01:00
variables:
PYTHONUTF8: "1"
Add Windows native static build using msvc to CI
2022-01-14 17:01:16 +01:00
script:
# FIXME: These should use --wrap-mode=nodownload but the Windows CI machines
# aren’t currently set up for that.
ci: Explicitly specify Python installation path on Windows Meson used to try and guess at the Python path. While this worked fine for GLib before, it probably didn’t work 100% for other projects, so Meson have made it an explicit option. Set that option with the Python path used on the Windows CI machines. This fixes a Meson warning with Meson >0.60. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-05-06 14:46:53 +02:00
- .gitlab-ci/test-msvc.bat ${MESON_COMMON_OPTIONS}
--wrap-mode=default
--default-library=static
--python.platlibdir=C:\Python37\site-packages
--python.purelibdir=C:\Python37\site-packages
Add Windows native static build using msvc to CI
2022-01-14 17:01:16 +01:00
artifacts:
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
Add Windows native static build using msvc to CI
2022-01-14 17:01:16 +01:00
name: "glib-${env:CI_JOB_NAME}-${env: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 13:54:54 +02:00
expire_in: 1 week
Add Windows native static build using msvc to CI
2022-01-14 17:01:16 +01:00
paths:
- _build/meson-logs
ci: Replace FreeBSD 11 with FreeBSD 13 FreeBSD 11 will go EOL in a month, and FreeBSD 13 was released several months ago. Remove the FreeBSD 11 job and add a FreeBSD 13 job.
2021-09-02 19:53:26 +02:00
freebsd-13-x86_64:
ci: Allow to run jobs that only run in origin repos manually
2024-01-25 16:45:25 +01:00
extends: .only-origin-or-manual
ci: Enable CI on FreeBSD 12
2019-06-24 16:55:36 +02:00
stage: build
tags:
ci: Replace FreeBSD 11 with FreeBSD 13 FreeBSD 11 will go EOL in a month, and FreeBSD 13 was released several months ago. Remove the FreeBSD 11 job and add a FreeBSD 13 job.
2021-09-02 19:53:26 +02:00
- freebsd-13
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 13:00:57 +02:00
needs: []
ci: Enable CI on FreeBSD 12
2019-06-24 16:55:36 +02:00
variables:
CPPFLAGS: -I/usr/local/include
LDFLAGS: -L/usr/local/lib -Wl,--disable-new-dtags
ci: Use C.UTF-8 locale on FreeBSD 12
2021-09-02 18:51:14 +02:00
LANG: C.UTF-8
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 15:35:54 +01:00
before_script:
- bash .gitlab-ci/show-execution-environment.sh
ci: Enable CI on FreeBSD 12
2019-06-24 16:55:36 +02:00
script:
ci: Temporarily disable --fatal-meson-warnings on FreeBSD CI For the same reasons as in commit 71061fdcb33b8c26f5f8467c, but in this case we can’t downgrade the version of Meson on the CI runner, so just tell it to shut up instead. Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-01-03 13:54:02 +01:00
# FIXME: We can’t use ${MESON_COMMON_OPTIONS} here because the FreeBSD 13
# runner has Meson 1.3 installed. This has an API hole where previous
# methods of getting paths from files() objects are rejected as deprecated,
# but no replacements are available. Hence, we can’t build with
# --fatal-meson-warnings. This should be fixed in Meson 1.4. It’s also fine
# with Meson 1.2.3 (which is what we use on all the other CI runners).
# See https://github.com/GNOME/glib/commit/71061fdcb33b8c26f5f8467cb3ac10704d65c87d
- meson setup --buildtype debug --wrap-mode=nodownload --localstatedir=/var -Db_lundef=false -Dxattr=false _build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson compile -C _build
ci: Enable CI on FreeBSD 12
2019-06-24 16:55:36 +02:00
- bash -x ./.gitlab-ci/run-tests.sh
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 13:45:51 +01:00
artifacts:
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
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 13:45:51 +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 13:54:54 +02:00
expire_in: 1 week
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 13:45:51 +01:00
paths:
- "_build/config.h"
- "_build/glib/glibconfig.h"
- "_build/meson-logs"
Re-enable macOS CI on a new self-hosted runner Allow two more tests to fail on macOS for the time being: https://gitlab.gnome.org/GNOME/glib/-/issues/3069 https://gitlab.gnome.org/GNOME/glib/-/issues/3070
2023-08-03 23:37:18 +02:00
macos-x86_64:
ci: Allow to run jobs that only run in origin repos manually
2024-01-25 16:45:25 +01:00
extends: .only-origin-or-manual
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 13:45:51 +01:00
stage: build
tags:
Re-enable macOS CI on a new self-hosted runner Allow two more tests to fail on macOS for the time being: https://gitlab.gnome.org/GNOME/glib/-/issues/3069 https://gitlab.gnome.org/GNOME/glib/-/issues/3070
2023-08-03 23:37:18 +02:00
- macosintel
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 13:00:57 +02:00
needs: []
Re-enable macOS CI on a new self-hosted runner Allow two more tests to fail on macOS for the time being: https://gitlab.gnome.org/GNOME/glib/-/issues/3069 https://gitlab.gnome.org/GNOME/glib/-/issues/3070
2023-08-03 23:37:18 +02:00
cache: []
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 02:31:02 +02:00
variables:
GIT_SUBMODULE_STRATEGY: normal
Re-enable macOS CI on a new self-hosted runner Allow two more tests to fail on macOS for the time being: https://gitlab.gnome.org/GNOME/glib/-/issues/3069 https://gitlab.gnome.org/GNOME/glib/-/issues/3070
2023-08-03 23:37:18 +02:00
# -Wno-overlength-strings
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 15:16:23 +02: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
Re-enable macOS CI on a new self-hosted runner Allow two more tests to fail on macOS for the time being: https://gitlab.gnome.org/GNOME/glib/-/issues/3069 https://gitlab.gnome.org/GNOME/glib/-/issues/3070
2023-08-03 23:37:18 +02:00
CFLAGS: "-Wno-overlength-strings"
# redirect to the runner's volatile temporary directory
TMPDIR: /Users/Shared/work/tmp
# keep the user profile clean
PIP_CACHE_DIR: /Users/Shared/build/cache
PIPENV_CACHE_DIR: $PIP_CACHE_DIR
PYTHONPYCACHEPREFIX: $PIP_CACHE_DIR
# target OS X 10.9 Mavericks for backward compatibility
SDKROOT: /opt/sdks/MacOSX10.9.sdk
# use the runner's ccache directory
CCACHE_DIR: /Users/Shared/work/ccache
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 13:45:51 +01: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 15:35:54 +01:00
- bash .gitlab-ci/show-execution-environment.sh
Re-enable macOS CI on a new self-hosted runner Allow two more tests to fail on macOS for the time being: https://gitlab.gnome.org/GNOME/glib/-/issues/3069 https://gitlab.gnome.org/GNOME/glib/-/issues/3070
2023-08-03 23:37:18 +02:00
- python3 -m venv .venv
- ln -s /opt/cmake/CMake.app/Contents/bin/cmake .venv/bin
- ln -s /opt/ccache/ccache .venv/bin
- source .venv/bin/activate
build: Bump Meson dependency to 1.2.0 And update all the CI builds to use the latest micro release from that series, 1.2.3. This version bump means we can: - Drop some backwards-compatibility Meson checks - Fix a periodic CI failure caused by a now-fixed Meson bug (https://github.com/mesonbuild/meson/pull/10633) It’s in line with our [Meson version policy](./docs/meson-version.md), as Meson 1.2.1 is available in [Debian Trixie](https://packages.debian.org/source/trixie/meson) and the [freedesktop SDK](https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/c95902f2ed5cb7d9b8e352135facc539029ef6c9/elements/components/meson.bst). Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
2023-10-24 17:46:36 +02:00
- pip3 install meson==1.2.3
Re-enable macOS CI on a new self-hosted runner Allow two more tests to fail on macOS for the time being: https://gitlab.gnome.org/GNOME/glib/-/issues/3069 https://gitlab.gnome.org/GNOME/glib/-/issues/3070
2023-08-03 23:37:18 +02:00
- pip3 install ninja==1.11.1
Switch from the deprecated distutils module to the packaging module The distutils module was removed in Python 3.12.
2023-12-01 16:53:50 +01:00
- pip3 install packaging==23.2
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 13:45:51 +01:00
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 16:30:44 +01: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
meson: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${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 16:30:44 +01: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 16:43:59 +01: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 13:45:51 +01:00
_build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson compile -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-18 00:01:35 +01:00
- .gitlab-ci/run-tests.sh
ci: Enable CI on FreeBSD 12
2019-06-24 16:55:36 +02: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 21:53:11 +02: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 17:14:25 +02: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 13:54:54 +02: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 17:14:25 +02:00
paths:
ci: Enable FreeBSD CI
2018-09-28 19:01:12 +02: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 17:14:25 +02:00
- "_build/meson-logs"
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: 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 12:38:25 +01:00
extends: .only-default
ci: Use variables for docker images
2020-01-13 18:45:00 +01:00
image: $FEDORA_IMAGE
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
stage: coverage
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 13:00:57 +02:00
needs: ['fedora-x86_64', 'msys2-mingw32']
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
artifacts:
ci: Clarify artifact naming Put the job name and commit identifier in the artifact names. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-05-29 11:54:29 +02:00
name: "glib-${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
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 13:54:54 +02:00
expire_in: 1 week
ci: Expose the coverage report as link in the MR's It's making handier to check how changes are tested.
2022-07-14 21:51:51 +02:00
expose_as: 'Coverage Report'
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
paths:
ci: Expose the coverage report as link in the MR's It's making handier to check how changes are tested.
2022-07-14 21:51:51 +02:00
- _coverage/coverage/index.html
- _coverage
ci: Generate Cobertura XML and use it to feed gitlab for MR integration gitlab has coverage integration in MRs, but we need a cobertura formatted XML files (each must be less than 10 MB [1]) to show it, so generate it using a python script and inform gitlab about it. See https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html [1] https://gitlab.com/gitlab-org/gitlab/-/issues/328772#note_840831654
2022-07-21 01:05:42 +02:00
reports:
coverage_report:
coverage_format: cobertura
path: _coverage/*-cobertura/cobertura-*.xml
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 15:35:54 +01:00
before_script:
- bash .gitlab-ci/show-execution-environment.sh
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
script:
- bash -x ./.gitlab-ci/coverage-docker.sh
ci: Add a regex to parse line coverage statistics from genhtml output GitLab can then use this to annotate each pipeline with its code coverage statistics. It can only use one figure, so we choose lines (rather than function or branch coverage) since it’s the most intuitive figure. This parses the ‘lines’ line from output like: Overall coverage rate: lines......: 76.7% (108959 of 142122 lines) functions..: 80.7% (10294 of 12763 functions) branches...: 51.3% (50226 of 97953 branches) Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-05-25 00:43:03 +02:00
coverage: '/^\s+lines\.+:\s+([\d.]+\%)\s+/'
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
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-28 00:32:39 +01: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 13:30:19 +01: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 13:33:09 +01:00
- .build-linux
ci: Add ability to run manually some specific jobs In some merge requests there are bits (such as memory leaks) that we may want to test before merging and that the schedules will run them. As per this add a rule to make them manual, and apply it to some jobs.
2024-01-23 19:18:54 +01:00
- .only-schedules-or-manual
ci: Use variables for docker images
2020-01-13 18:45:00 +01: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-28 00:32:39 +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 13:00:57 +02: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-28 00:32:39 +01:00
script:
meson: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${MESON_COMMON_OPTIONS}
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-28 00:32:39 +01:00
--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 14:16:57 +01: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-28 00:32:39 +01:00
--libdir=lib
-Dsystemtap=true
-Ddtrace=true
-Dinstalled_tests=true
ci: Build with introspection enabled In most CI builds. (Not all of them, though, so we can also test the build works with it disabled.) This is needed for the upcoming libgirepository tests, as they need some GIR files to test against. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3155
2023-11-28 19:00:35 +01:00
-Dintrospection=enabled
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 15:31:42 +02: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-28 00:32:39 +01: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 13:54:54 +02: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-28 00:32:39 +01: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 15:31:42 +02: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-28 00:32:39 +01:00
ci: Disable the Coverity CI job It’s not produced anything but false positives for several years now, and it would be better to save the CI/analysis/triage resources and instead focus on `scan_build` reports, which generally seem to be more useful. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-04-26 15:30:20 +02: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 13:30:19 +01: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 13:33:09 +01:00
- .build-linux
ci: Run docs and coverity builds only on schedules in default branch Also allow running them manually if required, but this still needs to be done from a GNOME/glib:main pipeline.
2024-01-25 17:07:46 +01:00
- .only-schedules-or-manual-in-default-branch
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 13:39:24 +02:00
image: $COVERITY_IMAGE
stage: analysis
needs: []
variables:
# cov-build doesn’t like GLIB_DEPRECATED_ENUMERATOR
CFLAGS: '-DGLIB_DISABLE_DEPRECATION_WARNINGS'
script:
meson: Use 'meson setup' to configure This removes a deprecation warning when using 'meson' without 'setup'.
2023-08-14 13:24:28 +02:00
- meson setup ${MESON_COMMON_OPTIONS}
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 13:39:24 +02:00
--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 14:16:57 +01: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 13:39:24 +02:00
--libdir=lib
-Dsystemtap=true
-Ddtrace=true
-Dinstalled_tests=true
ci: Build with introspection enabled In most CI builds. (Not all of them, though, so we can also test the build works with it disabled.) This is needed for the upcoming libgirepository tests, as they need some GIR files to test against. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3155
2023-11-28 19:00:35 +01:00
-Dintrospection=enabled
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 13:39:24 +02:00
_coverity_build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- $HOME/cov-analysis-linux64-*/bin/cov-build --dir cov-int meson compile -C _coverity_build
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 13:39:24 +02:00
- 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 13:54:54 +02: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 13:39:24 +02:00
paths:
- "cov-int/build-log.txt"
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
pages:
ci: Fix post-merge CI pipelines Don’t allow the `pages` job to be run (even manually) on post-merge pipelines. It’s not particularly useful, and GitLab doesn’t like having a manual job with unsatisfied dependencies in a pipeline: ``` 'pages' job needs 'coverage' job, but 'coverage' is not in any previous stage 'pages' job needs 'style-check-advisory' job, but 'style-check-advisory' is not in any previous stage ``` See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3847#note_1986044 Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-01-25 21:31:34 +01:00
extends: .only-schedules
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
stage: deploy
ci: Rename `style-check-diff` to `style-check-advisory` To better reflect its purpose. This will also help distinguish it from a job being added in a following commit. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-11-02 17:46:15 +01:00
needs: ['coverage', 'style-check-advisory']
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
script:
- mv _coverage/ public/
artifacts:
paths:
- public
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
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 15:59:29 +01:00
dist-job:
ci: Use variables for docker images
2020-01-13 18:45:00 +01: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 15:59:29 +01: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
docs: Port the man pages from DocBook to reStructuredText So they are consistent with the way we’re building man pages in other projects, and because some people are allergic to XML. This changes the build-time dependencies from `xsltproc` to `rst2man`, and also takes the opportunity to change the `-Dman` Meson option from a boolean to a feature (so you should use `-Dman-pages={enabled,disabled}` now, rather than `-Dman={true,false}`). Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2023-12-20 15:04:11 +01:00
- meson setup ${MESON_COMMON_OPTIONS} --buildtype release -Ddocumentation=true -Dman-pages=enabled _build
ci: Use `meson compile` rather than bare `ninja` This makes it more consistent with `meson setup` in the rest of the file.
2023-08-16 13:57:47 +02:00
- meson dist -C _build
ci: Fix tarballing the docs on dist The generated docs are discarded by `meson dist` after building the dist tarball, so we need to compile them again. And they get generated in the `_build` directory, not the source directory. Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-01-04 18:41:30 +01:00
# Compile again to build the docs
- meson compile -C _build
- tar -c -J -f "glib-docs-$CI_COMMIT_TAG.tar.xz" -C _build/docs/reference/glib glib
- tar -c -J -f "gmodule-docs-$CI_COMMIT_TAG.tar.xz" -C _build/docs/reference/gmodule gmodule
- tar -c -J -f "gobject-docs-$CI_COMMIT_TAG.tar.xz" -C _build/docs/reference/gobject gobject
- tar -c -J -f "gio-docs-$CI_COMMIT_TAG.tar.xz" -C _build/docs/reference/gio gio
ci: Build and tar libgirepository documentation Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-02-12 18:01:15 +01:00
- tar -c -J -f "girepository-docs-$CI_COMMIT_TAG.tar.xz" -C _build/docs/reference/girepository girepository
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 15:59:29 +01: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: Update docs build for the release job Not that this job is particularly maintained at the moment, but at least try to keep it up to date. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2023-12-12 15:59:42 +01:00
- "${CI_PROJECT_DIR}/_build/gmodule-docs-$CI_COMMIT_TAG.tar.xz"
ci: Fix paths for dist'ed documentation
2020-04-28 13:28:50 +02:00
- "${CI_PROJECT_DIR}/_build/gobject-docs-$CI_COMMIT_TAG.tar.xz"
- "${CI_PROJECT_DIR}/_build/gio-docs-$CI_COMMIT_TAG.tar.xz"
ci: Build and tar libgirepository documentation Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-02-12 18:01:15 +01:00
- "${CI_PROJECT_DIR}/_build/girepository-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 15:59:29 +01: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