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

82 lines
1.9 KiB
YAML
Raw Normal View History

ci: update meson Rebuild the fedora docker image to get the newest meson release and use pip to install the newest version for MSYS2. https://bugzilla.gnome.org/show_bug.cgi?id=795711
2018-05-01 08:55:29 +02:00
image: registry.gitlab.gnome.org/gnome/glib/master:v1
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:
- 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
- deploy
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: Rename `build-job` to `fedora-meson-x86_64` for uniqueness Makes it a bit more easily differentiable from the new `msys2-mingw32` job. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-04-26 11:05:45 +02:00
fedora-meson-x86_64:
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: 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:
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 --prefix /usr --libdir /usr/lib64 --buildtype debug --werror -Dsystemtap=true -Ddtrace=true _build .
- cd _build
- ninja
ci: use timeout-multiplier=2 for running the tests It looks like the coverage generation makes the tests a bit slower and some are now hitting timeouts. Flaky tests are always more annoying than slow ones, and we don't know how much resources we get under CI, so increase the timeout. https://bugzilla.gnome.org/show_bug.cgi?id=795636
2018-05-02 13:54:49 +02:00
- meson test --timeout-multiplier 2
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
- cd ..
- mkdir -p _coverage
- lcov --rc lcov_branch_coverage=1 --directory . --capture --no-external --output-file "_coverage/${CI_JOB_NAME}.lcov"
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
except:
- tags
artifacts:
name: "glib-_${CI_COMMIT_REF_NAME}"
paths:
- "${CI_PROJECT_DIR}/_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
- "${CI_PROJECT_DIR}/_coverage"
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
msys2-mingw32:
stage: build
tags:
- win32
variables:
MSYSTEM: "MINGW32"
CHERE_INVOKING: "yes"
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu --ask 20
- 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:
paths:
- _coverage/
coverage:
stage: coverage
artifacts:
paths:
- _coverage/
script:
- bash -x ./.gitlab-ci/coverage-docker.sh
pages:
stage: deploy
script:
- mv _coverage/ public/
artifacts:
paths:
- public
only:
- master
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:
stage: build
only:
- tags
script:
- meson --prefix /usr --libdir /usr/lib64 --buildtype release -Dgtk_doc=true -Dman=true _build .
- cd _build
- ninja dist
- ninja glib-doc
- tar -c -f "glib-docs-$CI_COMMIT_TAG.tar.xz" -C docs/reference/glib html
- tar -c -f "gobject-docs-$CI_COMMIT_TAG.tar.xz" -C docs/reference/gobject html
- tar -c -f "gio-docs-$CI_COMMIT_TAG.tar.xz" -C docs/reference/gio html
artifacts:
paths:
- "${CI_PROJECT_DIR}/_build/glib-docs.tar.xz"
- "${CI_PROJECT_DIR}/_build/gobject-docs.tar.xz"
- "${CI_PROJECT_DIR}/_build/gio-docs.tar.xz"
- "${CI_PROJECT_DIR}/_build/meson-dist/glib-*.tar.xz"
Reference in New Issue Copy Permalink