AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-11-09 18:30:08 +00:00
Code Issues Projects Releases Wiki Activity
21e9a508bd
gtk/.gitlab-ci.yml

403 lines
11 KiB
YAML
Raw Normal View History

ci: publish demo apps to the Nightly repository
2020-11-13 18:00:17 +00:00
include:
- project: 'gnome/citemplates'
file: 'flatpak/flatpak_ci_initiative.yml'
Add gitlab-ci support using a prebuilt docker image
2018-02-13 16:21:18 +00:00
stages:
ci: Move style check to its own stage Drop the `.pre` phase.
2022-09-09 22:39:20 +00:00
- check
Add gitlab-ci support using a prebuilt docker image
2018-02-13 16:21:18 +00:00
- build
ci: Add a static analysis job Use the Clang static analysis tool. For the time being, we're going to allow it to fail, but the plan is to fix every issue it raises.
2020-02-25 19:06:39 +00:00
- analysis
ci: Add a separate "docs" stage Don't build the API reference on deploy; build it in a separate job, instead, so we can run it on all pipelines, and deploy it only for master.
2020-02-25 16:42:07 +00:00
- docs
ci: Deploy the API ref before flatpak
2020-02-12 18:10:49 +00:00
- flatpak
ci: Trigger a pages build Do not publish the API reference directly, but trigger a CI pipeline for the docs-gtk-org branch, which will then do the publishing.
2021-07-31 16:08:56 +00:00
- publish
ci: Add a separate "docs" stage Don't build the API reference on deploy; build it in a separate job, instead, so we can run it on all pipelines, and deploy it only for master.
2020-02-25 16:42:07 +00:00
- deploy
Add gitlab-ci support using a prebuilt docker image
2018-02-13 16:21:18 +00:00
gitlab-ci: Reenable ccache but disable it during the initial meson call There where some problems (??) with ccache not detecting changes during meson checks. Setting CCACHE_DISABLE during the meson execution makes ccache not use the cache and pass things directly to the compiler.
2018-04-11 10:18:55 +00:00
.cache-paths: &cache-paths
paths:
- _ccache/
- subprojects/gdk-pixbuf/
- subprojects/glib/
- subprojects/graphene/
- subprojects/libepoxy/
- subprojects/pango/
ci: Refactor the CI pipeline We should have a single job for building both static and shared versions of GTK. On the other hand, having a separate job for the release build would be a plus. Additionally, we shouldn't use an opaque script to build GTK; the only step in the process that requires hand-holding is running the tests suites under Xvfb, and having the build options visible from the YAML file gives us a better idea of what kind of build we're running.
2020-01-29 09:35:10 +00:00
# Common variables
variables:
ci: Disable -Werror on wayland submodule CI is mostly interested in GTK not introducing compiler warnings, other submodules like Wayland might have their own and that shouldn't hinder CI testing of GTK. Disable -Werror for the wayland submodule, and let it be fixed independently at some point.
2022-08-10 14:35:28 +00:00
COMMON_MESON_FLAGS: "-Dwerror=true -Dglib:werror=false -Dpango:werror=false -Dgtk-doc:werror=false -Dwayland-protocols:werror=false -Dsysprof:werror=false -Dwayland:werror=false"
build: Start using meson feature options Use feature options for things that are optional features, update the docs. Visible changes here is that the 'print-backends' option got renamed to 'print' to go better with 'media', and the 'tracker3' option got renamed to 'tracker'. For options that have been changed into features, the syntax now is -Dfeature=enabled or -Dfeature=disabled or -Dfeature=auto.
2020-08-21 23:36:17 +00:00
BACKEND_FLAGS: "-Dx11-backend=true -Dwayland-backend=true -Dbroadway-backend=true"
FEATURE_FLAGS: "-Dvulkan=enabled -Dcloudproviders=enabled"
ci: Increase the timeout multiplier We do have some slow tests.
2020-07-10 15:08:59 +00:00
MESON_TEST_TIMEOUT_MULTIPLIER: 3
ci: Update the Fedora image
2022-12-20 01:34:45 +00:00
FEDORA_IMAGE: "registry.gitlab.gnome.org/gnome/gtk/fedora:v40"
Update (or drop) the Docker image used by Flatpak job The gnome-runtime-images have been recently migrated to Quay. This is already reflected in the template. Please note this MR has been created semi-automatically. If it doesn't make sense, feel free to close it.
2022-07-27 10:47:50 +00:00
FLATPAK_IMAGE: "quay.io/gnome_infrastructure/gnome-runtime-images:gnome-master"
ci: Refactor the CI pipeline We should have a single job for building both static and shared versions of GTK. On the other hand, having a separate job for the release build would be a plus. Additionally, we shouldn't use an opaque script to build GTK; the only step in the process that requires hand-holding is running the tests suites under Xvfb, and having the build options visible from the YAML file gives us a better idea of what kind of build we're running.
2020-01-29 09:35:10 +00:00
ci: Add a style check pass We should at least try to get the style check done by a machine, as opposed to have humans go through merge requests with coding style nitpicks.
2020-02-11 13:28:16 +00:00
.only-default:
only:
- branches
except:
- tags
style-check-diff:
extends: .only-default
ci: Move images into environment variables Currently we have to hunt all the `image` keys when updating the image in use for a job. We should centralise them all at the top of the file, so they are easy to update in one simple change.
2020-06-08 10:00:20 +00:00
image: $FEDORA_IMAGE
ci: Move style check to its own stage Drop the `.pre` phase.
2022-09-09 22:39:20 +00:00
stage: check
ci: Add a style check pass We should at least try to get the style check done by a machine, as opposed to have humans go through merge requests with coding style nitpicks.
2020-02-11 13:28:16 +00:00
allow_failure: true
script:
- .gitlab-ci/run-style-check-diff.sh
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
.build-fedora-default:
ci: Specify `only` for other jobs Otherwise MRs will only run macOS jobs.
2021-01-07 16:03:10 +00:00
extends: .only-default
ci: Move images into environment variables Currently we have to hunt all the `image` keys when updating the image in use for a job. We should centralise them all at the top of the file, so they are easy to update in one simple change.
2020-06-08 10:00:20 +00:00
image: $FEDORA_IMAGE
ci: Store the logs on build failure We should save the logs directory when the CI pipeline fails, so that we have a chance at debugging the failure.
2018-03-01 10:09:22 +00:00
artifacts:
ci: Add JUnit report for the test suite We can convert the JSON output for `meson test` into a JUnix XML report, which can be consumed by GitLab.
2019-04-05 17:23:13 +00:00
when: always
reports:
junit:
ci: Run tests with different backends Run the testsuite under x11, wayland and broadway in the fedora-x86_64 job. This requires us to use the v17 image which includes weston.
2020-05-15 13:44:24 +00:00
- "${CI_PROJECT_DIR}/_build/report-x11.xml"
testsuite: Use separate setups for unstable tests instead of should_fail There are two possible interpretations of "expected failure": either the test *must* fail (exactly the inverse of an ordinary test, with success becoming failure and failure becoming success), or the test *may* fail (with success intended, but failure possible in some environments). Autotools had the second interpretation, which seems more useful in practice, but Meson has the first. Instead of using should_fail, we can put the tests in one of two new suites: "flaky" is intended for tests that succeed or fail unpredictably according to the test environment or chance, while "failing" is for tests that ought to succeed but currently never do as a result of a bug or missing functionality. With a sufficiently new version of Meson, the flaky and failing tests are not run by default, but can be requested by running a setup that does not exclude them, with a command like: meson test --setup=x11_unstable --suite=flaky --suite=failing As a bonus, now that we're setting up setups and their excluded suites programmatically, the gsk-compare-broadway tests are also excluded by default when running the test setup for a non-broadway backend. When running the tests in CI, --suite=gtk overrides the default exclude_suites, so we have to specify --no-suite=flaky and --no-suite=failing explicitly. This arrangement is inspired by GNOME/glib!2987, which was contributed by Marco Trevisan. Signed-off-by: Simon McVittie <smcv@debian.org>
2022-11-23 19:13:32 +00:00
- "${CI_PROJECT_DIR}/_build/report-x11_unstable.xml"
ci: Run tests with different backends Run the testsuite under x11, wayland and broadway in the fedora-x86_64 job. This requires us to use the v17 image which includes weston.
2020-05-15 13:44:24 +00:00
- "${CI_PROJECT_DIR}/_build/report-wayland.xml"
testsuite: Use separate setups for unstable tests instead of should_fail There are two possible interpretations of "expected failure": either the test *must* fail (exactly the inverse of an ordinary test, with success becoming failure and failure becoming success), or the test *may* fail (with success intended, but failure possible in some environments). Autotools had the second interpretation, which seems more useful in practice, but Meson has the first. Instead of using should_fail, we can put the tests in one of two new suites: "flaky" is intended for tests that succeed or fail unpredictably according to the test environment or chance, while "failing" is for tests that ought to succeed but currently never do as a result of a bug or missing functionality. With a sufficiently new version of Meson, the flaky and failing tests are not run by default, but can be requested by running a setup that does not exclude them, with a command like: meson test --setup=x11_unstable --suite=flaky --suite=failing As a bonus, now that we're setting up setups and their excluded suites programmatically, the gsk-compare-broadway tests are also excluded by default when running the test setup for a non-broadway backend. When running the tests in CI, --suite=gtk overrides the default exclude_suites, so we have to specify --no-suite=flaky and --no-suite=failing explicitly. This arrangement is inspired by GNOME/glib!2987, which was contributed by Marco Trevisan. Signed-off-by: Simon McVittie <smcv@debian.org>
2022-11-23 19:13:32 +00:00
- "${CI_PROJECT_DIR}/_build/report-wayland_unstable.xml"
ci: Run tests with different backends Run the testsuite under x11, wayland and broadway in the fedora-x86_64 job. This requires us to use the v17 image which includes weston.
2020-05-15 13:44:24 +00:00
- "${CI_PROJECT_DIR}/_build/report-broadway.xml"
testsuite: Use separate setups for unstable tests instead of should_fail There are two possible interpretations of "expected failure": either the test *must* fail (exactly the inverse of an ordinary test, with success becoming failure and failure becoming success), or the test *may* fail (with success intended, but failure possible in some environments). Autotools had the second interpretation, which seems more useful in practice, but Meson has the first. Instead of using should_fail, we can put the tests in one of two new suites: "flaky" is intended for tests that succeed or fail unpredictably according to the test environment or chance, while "failing" is for tests that ought to succeed but currently never do as a result of a bug or missing functionality. With a sufficiently new version of Meson, the flaky and failing tests are not run by default, but can be requested by running a setup that does not exclude them, with a command like: meson test --setup=x11_unstable --suite=flaky --suite=failing As a bonus, now that we're setting up setups and their excluded suites programmatically, the gsk-compare-broadway tests are also excluded by default when running the test setup for a non-broadway backend. When running the tests in CI, --suite=gtk overrides the default exclude_suites, so we have to specify --no-suite=flaky and --no-suite=failing explicitly. This arrangement is inspired by GNOME/glib!2987, which was contributed by Marco Trevisan. Signed-off-by: Simon McVittie <smcv@debian.org>
2022-11-23 19:13:32 +00:00
- "${CI_PROJECT_DIR}/_build/report-broadway_unstable.xml"
ci: Store the logs on build failure We should save the logs directory when the CI pipeline fails, so that we have a chance at debugging the failure.
2018-03-01 10:09:22 +00:00
name: "gtk-${CI_COMMIT_REF_NAME}"
paths:
ci: Use the right path for the logs The meson-logs directory is under the `_build` directory.
2018-03-01 10:23:14 +00:00
- "${CI_PROJECT_DIR}/_build/meson-logs"
ci: Run tests with different backends Run the testsuite under x11, wayland and broadway in the fedora-x86_64 job. This requires us to use the v17 image which includes weston.
2020-05-15 13:44:24 +00:00
- "${CI_PROJECT_DIR}/_build/report*.xml"
- "${CI_PROJECT_DIR}/_build/report*.html"
- "${CI_PROJECT_DIR}/_build/testsuite/reftests/output/*/*.png"
CI: Include reftest nodes in artifacts
2022-05-18 17:13:39 +00:00
- "${CI_PROJECT_DIR}/_build/testsuite/reftests/output/*/*.node"
ci: Collect tools test output This should help understanding why some of them fail.
2021-07-28 17:41:33 +00:00
- "${CI_PROJECT_DIR}/_build/testsuite/tools/output/*/*"
ci: Run tests with different backends Run the testsuite under x11, wayland and broadway in the fedora-x86_64 job. This requires us to use the v17 image which includes weston.
2020-05-15 13:44:24 +00:00
- "${CI_PROJECT_DIR}/_build/testsuite/gsk/compare/*/*/*.png"
- "${CI_PROJECT_DIR}/_build/testsuite/css/output/*/*.syscap"
ci: Collect hello build logs
2021-06-09 11:35:25 +00:00
- "${CI_PROJECT_DIR}/_build_hello/meson-logs"
gitlab-ci: Reenable ccache but disable it during the initial meson call There where some problems (??) with ccache not detecting changes during meson checks. Setting CCACHE_DISABLE during the meson execution makes ccache not use the cache and pass things directly to the compiler.
2018-04-11 10:18:55 +00:00
cache:
key: "$CI_JOB_NAME"
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
paths:
- _ccache/
fedora-x86_64:
extends: .build-fedora-default
stage: build
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
variables:
EXTRA_MESON_FLAGS: "--buildtype=debug --default-library=both"
script:
ci: Show OS release for our containers
2021-05-05 20:22:32 +00:00
- .gitlab-ci/show-info-linux.sh
ci: Redefine PATH
2022-12-14 18:35:52 +00:00
- export PATH="$HOME/.local/bin:$PATH"
ci: Install Meson in the build jobs We use the latest 0.64 even if we depend on 0.60 because of fixes in the subproject command.
2022-12-14 17:09:34 +00:00
- pip3 install --user meson~=0.64
ci: Download the subprojects Updating the subprojects will apparently fail if they haven't been downloaded.
2022-11-26 14:28:00 +00:00
- meson subprojects download
ci: Always update subprojects to latest revision Otherwise we're not actually updating anything. `meson subprojects download` will skip subprojects that already exist.
2022-12-19 03:38:28 +00:00
- meson subprojects update --reset
ci: Test building against installed GTK This is meant to ensure that we e.g. install the right header files, and so on.
2021-06-08 21:39:34 +00:00
- mkdir _install
ci: Redefine PATH
2022-12-14 18:35:52 +00:00
- meson setup
--prefix=${CI_PROJECT_DIR}/_install
${COMMON_MESON_FLAGS}
${EXTRA_MESON_FLAGS}
${BACKEND_FLAGS}
${FEATURE_FLAGS}
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
_build
ci: Test building against installed GTK This is meant to ensure that we e.g. install the right header files, and so on.
2021-06-08 21:39:34 +00:00
- meson compile -C _build
- meson install -C _build
- PKG_CONFIG_PATH=${CI_PROJECT_DIR}/_install/lib64/pkgconfig:${CI_PROJECT_DIR}/_install/share/pkgconfig meson setup _build_hello examples/hello
wayland/surface: Use wl_surface_offset() instead of x,y of attach() This makes the hotspot of DND surfaces work when using the Vulkan and OpenGL renderers. This bumps the CI image used to the newly built image. This is needed to install a new enough libwayland-client.so needed for wl_surface.offset. This is done by adding wayland as a meson subproject, building it on-demand if the version in the system is not new enough. As libwayland-client.so is pulled in implicitly when linking to gtk4, the compile step needs LD_LIBRARY_PATH set to make ld find the right library to link to.
2021-03-22 10:51:37 +00:00
- LD_LIBRARY_PATH=${CI_PROJECT_DIR}/_install/lib64 meson compile -C _build_hello
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
- .gitlab-ci/run-tests.sh _build x11
- .gitlab-ci/run-tests.sh _build wayland
testsuite: Add run for GLES This is supposed to test the most fallback GL stuff, so we might want to set even more env vars here. Also enable the run for the Fedora builder in CI.
2021-10-08 16:38:51 +00:00
- .gitlab-ci/run-tests.sh _build waylandgles
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
- .gitlab-ci/run-tests.sh _build broadway
ci: Add two flatpak jobs When building GTK through the CI infrastructure, it would help to have some ways of testing it; for instance, if we want to verify that theme changes are useful, or if we want to run the result without necessarily build it locally. This is where flatpak comes in handy. By having the CI build a flatpak buundle, and storing it as an artifact, of the GTK demos, we can easily point developers and designers to an installable binary that won't break their system, nor will require development tools and environments to run.
2018-03-20 16:08:45 +00:00
ci: Split the static and shared builds (again) Sadly, we can't do a static build with the profiling code enabled because we don't have a static GLib build available.
2020-01-29 10:31:47 +00:00
release-build:
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
extends: .build-fedora-default
ci: Refactor the CI pipeline We should have a single job for building both static and shared versions of GTK. On the other hand, having a separate job for the release build would be a plus. Additionally, we shouldn't use an opaque script to build GTK; the only step in the process that requires hand-holding is running the tests suites under Xvfb, and having the build options visible from the YAML file gives us a better idea of what kind of build we're running.
2020-01-29 09:35:10 +00:00
stage: build
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
Try building static libs on CI
2019-11-11 19:11:16 +00:00
variables:
ci: Refactor the CI pipeline We should have a single job for building both static and shared versions of GTK. On the other hand, having a separate job for the release build would be a plus. Additionally, we shouldn't use an opaque script to build GTK; the only step in the process that requires hand-holding is running the tests suites under Xvfb, and having the build options visible from the YAML file gives us a better idea of what kind of build we're running.
2020-01-29 09:35:10 +00:00
EXTRA_MESON_FLAGS: "--buildtype=release"
script:
ci: Show OS release for our containers
2021-05-05 20:22:32 +00:00
- .gitlab-ci/show-info-linux.sh
ci: Redefine PATH
2022-12-14 18:35:52 +00:00
- export PATH="$HOME/.local/bin:$PATH"
ci: Install Meson in the build jobs We use the latest 0.64 even if we depend on 0.60 because of fixes in the subproject command.
2022-12-14 17:09:34 +00:00
- pip3 install --user meson~=0.64
ci: Download the subprojects Updating the subprojects will apparently fail if they haven't been downloaded.
2022-11-26 14:28:00 +00:00
- meson subprojects download
ci: Always update subprojects to latest revision Otherwise we're not actually updating anything. `meson subprojects download` will skip subprojects that already exist.
2022-12-19 03:38:28 +00:00
- meson subprojects update --reset
ci: Consistently use meson subcommands meson setup: configuration meson compile: compilation meson install installation Do not use ninja directly, and do not use `meson` as a synonym for `meson setup`.
2022-12-14 17:44:27 +00:00
- meson setup ${COMMON_MESON_FLAGS} ${EXTRA_MESON_FLAGS} ${BACKEND_FLAGS} ${FEATURE_FLAGS} _build
- meson compile -C _build
ci: Run tests with different backends Run the testsuite under x11, wayland and broadway in the fedora-x86_64 job. This requires us to use the v17 image which includes weston.
2020-05-15 13:44:24 +00:00
- .gitlab-ci/run-tests.sh _build x11
Try building static libs on CI
2019-11-11 19:11:16 +00:00
ci: add fedora-mingw64 job Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-01-06 12:01:40 +00:00
fedora-mingw64:
extends: .build-fedora-default
stage: build
needs: []
before_script:
- sudo dnf install -y
mingw64-filesystem
mingw64-gcc
mingw64-binutils
mingw64-cairo
mingw64-gdk-pixbuf
mingw64-gstreamer1-plugins-bad-free
mingw64-glib2
mingw64-libepoxy
mingw64-pango
# mingw64-graphene (rawhide)
script:
- .gitlab-ci/show-info-linux.sh
ci: Redefine PATH
2022-12-14 18:35:52 +00:00
- export PATH="$HOME/.local/bin:$PATH"
ci: Install Meson in the build jobs We use the latest 0.64 even if we depend on 0.60 because of fixes in the subproject command.
2022-12-14 17:09:34 +00:00
- pip3 install --user meson~=0.64
ci: Download the subprojects Updating the subprojects will apparently fail if they haven't been downloaded.
2022-11-26 14:28:00 +00:00
- meson subprojects download
ci: Always update subprojects to latest revision Otherwise we're not actually updating anything. `meson subprojects download` will skip subprojects that already exist.
2022-12-19 03:38:28 +00:00
- meson subprojects update --reset
ci: Fix fedora-mingw64 job
2022-12-18 05:37:43 +00:00
# Test that mingw64-meson still fails. If it has stopped failing, the CI
# will fail and now you should remove the hack that follows this.
- FAILED=false
- mingw64-meson --version || FAILED=true
- test $FAILED = false && echo "mingw64-meson works now, remove the hack" && exit 1
# HACK: Running mingw64-meson directly fails on the CI with:
# /usr/bin/mingw64-meson: line 92: fg: no job control
# Because rpm is not evaluating %__meson and it gets interpreted as a job
# specifier. So we fix that and run it ourselves.
- rpm --eval "%{mingw64_meson}" > mingw64-meson.sh
- sed -i -e 's/%__meson/meson/' mingw64-meson.sh
- chmod +x mingw64-meson.sh
- ./mingw64-meson.sh -Dintrospection=disabled -Dgraphene:introspection=disabled _build
- ninja -C _build
ci: add fedora-mingw64 job Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-01-06 12:01:40 +00:00
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
.mingw-defaults:
ci: Specify `only` for other jobs Otherwise MRs will only run macOS jobs.
2021-01-07 16:03:10 +00:00
extends: .only-default
gitlab-ci: Add a 32bit mingw build
2018-04-06 16:15:38 +00:00
stage: build
tags:
CI: Switch to new Windows runners They use powershell instead of cmd.exe, use the tag win32-ps instead of win32, and run Windows 2016 instead of 2012r2. The old runners will be switched off in the comming weeks.
2020-04-29 17:36:40 +00:00
- win32-ps
gitlab-ci: Add a 32bit mingw build
2018-04-06 16:15:38 +00:00
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
- C:\msys64\usr\bin\bash -lc "bash -x ./.gitlab-ci/test-msys2.sh"
gitlab-ci: Reenable ccache but disable it during the initial meson call There where some problems (??) with ccache not detecting changes during meson checks. Setting CCACHE_DISABLE during the meson execution makes ccache not use the cache and pass things directly to the compiler.
2018-04-11 10:18:55 +00:00
cache:
CI: use bash style variable expansion for the mingw cache key It doesn't understand the powershell syntax which leads to the cache key being empty which leads to cache restore being skipped which leads to slow builds not using ccache. See https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2747
2020-05-06 19:19:52 +00:00
key: "$CI_JOB_NAME"
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
paths:
- _ccache/
- subprojects/gdk-pixbuf/
- subprojects/glib/
- subprojects/graphene/
- subprojects/libepoxy/
- subprojects/pango/
gitlab-ci: Add a 32bit mingw build
2018-04-06 16:15:38 +00:00
CI: Switch to 64bit mingw for the MSYS2 job 64 bit is more common now and also tests more things because sizeof(glong) != sizeof(gpointer)
2020-06-14 18:02:46 +00:00
msys2-mingw64:
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
extends: .mingw-defaults
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
gitlab-ci: Add a 32bit mingw build
2018-04-06 16:15:38 +00:00
variables:
CI: Switch to 64bit mingw for the MSYS2 job 64 bit is more common now and also tests more things because sizeof(glong) != sizeof(gpointer)
2020-06-14 18:02:46 +00:00
MSYSTEM: "MINGW64"
gitlab-ci: Add a 32bit mingw build
2018-04-06 16:15:38 +00:00
CHERE_INVOKING: "yes"
Provide GTK DLL as GitLab CI artifact
2022-01-19 11:17:28 +00:00
artifacts:
when: always
ci: Only use letters in "expose_as"
2022-01-19 15:39:44 +00:00
expose_as: 'Windows_DLL_MSYS2_64_bit_toolchain'
Provide GTK DLL as GitLab CI artifact
2022-01-19 11:17:28 +00:00
paths:
ci: Put gtk dll into an archive This avoids the wild card that makes the CI fail
2022-01-19 15:37:36 +00:00
- "${CI_PROJECT_DIR}/_build/gtkdll.tar.gz"
gitlab-ci: Add a 32bit mingw build
2018-04-06 16:15:38 +00:00
Revert "Merge branch 'disable-macos-ci' into 'master'" This reverts merge request !3183
2021-02-12 19:40:57 +00:00
macos:
ci: Specify `only` for other jobs Otherwise MRs will only run macOS jobs.
2021-01-07 16:03:10 +00:00
extends: .only-default
ci: Only run macOS job on upstream branches Don't run CI on macOS for forks.
2021-01-07 16:14:04 +00:00
only:
- branches@GNOME/gtk
ci: Add a macos build Most of this is cribbed from glib. We don't use COMMON_MESON_FLAGS here, since disabling -Werror one subproject at a time is too painful for all the promoted sub-sub-projects. This needs a better solution in meson. Since this is a full rebuild of the entire stack, limit this to master and merge requests.
2021-01-03 03:34:52 +00:00
stage: build
tags:
- macos
needs: []
before_script:
ci: Show OS release for our containers
2021-05-05 20:22:32 +00:00
- bash .gitlab-ci/show-info-osx.sh
ci: Install Meson in the build jobs We use the latest 0.64 even if we depend on 0.60 because of fixes in the subproject command.
2022-12-14 17:09:34 +00:00
- pip3 install --user meson~=0.64
ci: Add a macos build Most of this is cribbed from glib. We don't use COMMON_MESON_FLAGS here, since disabling -Werror one subproject at a time is too painful for all the promoted sub-sub-projects. This needs a better solution in meson. Since this is a full rebuild of the entire stack, limit this to master and merge requests.
2021-01-03 03:34:52 +00:00
- pip3 install --user ninja
- export PATH=/Users/gitlabrunner/Library/Python/3.7/bin:$PATH
ci: Add debug spew on macos
2021-02-12 20:24:27 +00:00
- export MESON_FORCE_BACKTRACE=1
ci: Add a macos build Most of this is cribbed from glib. We don't use COMMON_MESON_FLAGS here, since disabling -Werror one subproject at a time is too painful for all the promoted sub-sub-projects. This needs a better solution in meson. Since this is a full rebuild of the entire stack, limit this to master and merge requests.
2021-01-03 03:34:52 +00:00
script:
ci: Consistently use meson subcommands meson setup: configuration meson compile: compilation meson install installation Do not use ninja directly, and do not use `meson` as a synonym for `meson setup`.
2022-12-14 17:44:27 +00:00
- meson setup
-Dx11-backend=false
ci: Build Broadway on MacOS We've seen a build failure if Broadway is built without the X11 backend. Lets recreate that configuration in ci so it doesn't break again.
2021-06-18 13:08:32 +00:00
-Dbroadway-backend=true
-Dmacos-backend=true
build: Set proper defaults for media backends GTK supports webm playback, which means a backend should always be compiled. The ffmpeg backend however is incomplete (no audio) and as such, we don't want people to end up with it accidentally. Since we don't want to drag an entire gstreamer build into our ci on MacOs or msvc, explicitly disable the gstreame media backend there.
2021-04-01 15:59:18 +00:00
-Dmedia-gstreamer=disabled
ci: Add a macos build Most of this is cribbed from glib. We don't use COMMON_MESON_FLAGS here, since disabling -Werror one subproject at a time is too painful for all the promoted sub-sub-projects. This needs a better solution in meson. Since this is a full rebuild of the entire stack, limit this to master and merge requests.
2021-01-03 03:34:52 +00:00
-Dintrospection=disabled
ci: Fix the harfbuzz build on MacOS We need to force c++11 at the toplevel here, since meson can't deal with per-project compiler choice.
2021-01-03 18:13:27 +00:00
-Dcpp_std=c++11
ci: Disable pixman tests on MacOS The pixman tests fail to build, and I don't have the stamina to fix all sub-sub-projects, so just disable the tests.
2021-01-03 18:23:45 +00:00
-Dpixman:tests=disabled
ci: Try to fix the macos build It seems that libjpeg-turbo first finds nasm, and then doesn't find it. Turn off simd to keep it from looking for it in the first place.
2022-10-29 01:03:56 +00:00
-Dlibjpeg-turbo:simd=disabled
ci: Add a macos build Most of this is cribbed from glib. We don't use COMMON_MESON_FLAGS here, since disabling -Werror one subproject at a time is too painful for all the promoted sub-sub-projects. This needs a better solution in meson. Since this is a full rebuild of the entire stack, limit this to master and merge requests.
2021-01-03 03:34:52 +00:00
_build
ci: Consistently use meson subcommands meson setup: configuration meson compile: compilation meson install installation Do not use ninja directly, and do not use `meson` as a synonym for `meson setup`.
2022-12-14 17:44:27 +00:00
- meson compile -C _build
ci: Add a macos build Most of this is cribbed from glib. We don't use COMMON_MESON_FLAGS here, since disabling -Werror one subproject at a time is too painful for all the promoted sub-sub-projects. This needs a better solution in meson. Since this is a full rebuild of the entire stack, limit this to master and merge requests.
2021-01-03 03:34:52 +00:00
artifacts:
when: always
paths:
- "${CI_PROJECT_DIR}/_build/meson-logs"
ci: Add MSVC build This script is copied from glib CI.
2021-04-29 15:09:04 +00:00
vs2017-x64:
extends: .only-default
# TODO: Uncomment this when ready to merge.
#only:
# - branches@GNOME/gtk
stage: build
tags:
- win32-ps
needs: []
script:
- .gitlab-ci/test-msvc.bat
artifacts:
when: always
paths:
- "${CI_PROJECT_DIR}/_build/meson-logs"
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
.flatpak-defaults:
ci: Move images into environment variables Currently we have to hunt all the `image` keys when updating the image in use for a job. We should centralise them all at the top of the file, so they are easy to update in one simple change.
2020-06-08 10:00:20 +00:00
image: $FLATPAK_IMAGE
ci: Add two flatpak jobs When building GTK through the CI infrastructure, it would help to have some ways of testing it; for instance, if we want to verify that theme changes are useful, or if we want to run the result without necessarily build it locally. This is where flatpak comes in handy. By having the CI build a flatpak buundle, and storing it as an artifact, of the GTK demos, we can easily point developers and designers to an installable binary that won't break their system, nor will require development tools and environments to run.
2018-03-20 16:08:45 +00:00
stage: flatpak
ci: Allow flatpak jobs to fail We have more accurate CI jobs, now; the Flatpak jobs are nice to have.
2020-02-13 17:09:35 +00:00
allow_failure: true
ci: Update flatpak jobs The CI infrastructure was changed to run with fewer privileges, so we need to adapt our Flatpak jobs to compensate. See: https://mail.gnome.org/archives/desktop-devel-list/2020-February/msg00055.html
2020-02-19 15:04:58 +00:00
tags:
- flatpak
ci: Add two flatpak jobs When building GTK through the CI infrastructure, it would help to have some ways of testing it; for instance, if we want to verify that theme changes are useful, or if we want to run the result without necessarily build it locally. This is where flatpak comes in handy. By having the CI build a flatpak buundle, and storing it as an artifact, of the GTK demos, we can easily point developers and designers to an installable binary that won't break their system, nor will require development tools and environments to run.
2018-03-20 16:08:45 +00:00
artifacts:
paths:
ci: Use a common section for Flatpak jobs Avoid repeating blobs of YAML manually, and use the proper YAML mechanism to copy-paste blobs instead.
2018-04-11 16:45:29 +00:00
- "${APPID}-dev.flatpak"
ci: publish demo apps to the Nightly repository
2020-11-13 18:00:17 +00:00
- 'repo.tar'
ci: Add two flatpak jobs When building GTK through the CI infrastructure, it would help to have some ways of testing it; for instance, if we want to verify that theme changes are useful, or if we want to run the result without necessarily build it locally. This is where flatpak comes in handy. By having the CI build a flatpak buundle, and storing it as an artifact, of the GTK demos, we can easily point developers and designers to an installable binary that won't break their system, nor will require development tools and environments to run.
2018-03-20 16:08:45 +00:00
expire_in: 1 day
ci: Use a common section for Flatpak jobs Avoid repeating blobs of YAML manually, and use the proper YAML mechanism to copy-paste blobs instead.
2018-04-11 16:45:29 +00:00
script:
- bash -x ./.gitlab-ci/flatpak-build.sh "${APPID}"
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
# Manual jobs, for branches and MRs
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
.flatpak-manual:
extends: .flatpak-defaults
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
when: manual
Update references to master in the repository
2021-11-29 22:37:49 +00:00
# Only build Flatpak bundles automatically on main
.flatpak-main:
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
extends: .flatpak-defaults
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
only:
Update references to master in the repository
2021-11-29 22:37:49 +00:00
- main
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
flatpak-manual:demo:
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
extends: .flatpak-manual
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
ci: Use a common section for Flatpak jobs Avoid repeating blobs of YAML manually, and use the proper YAML mechanism to copy-paste blobs instead.
2018-04-11 16:45:29 +00:00
variables:
gtk-demo: Rename to org.gtk.Demo4
2019-04-01 22:49:09 +00:00
APPID: org.gtk.Demo4
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
Update references to master in the repository
2021-11-29 22:37:49 +00:00
flatpak-main:demo:
extends: .flatpak-main
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
variables:
APPID: org.gtk.Demo4
ci: Add two flatpak jobs When building GTK through the CI infrastructure, it would help to have some ways of testing it; for instance, if we want to verify that theme changes are useful, or if we want to run the result without necessarily build it locally. This is where flatpak comes in handy. By having the CI build a flatpak buundle, and storing it as an artifact, of the GTK demos, we can easily point developers and designers to an installable binary that won't break their system, nor will require development tools and environments to run.
2018-03-20 16:08:45 +00:00
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
flatpak-manual:widget-factory:
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
extends: .flatpak-manual
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
ci: Use a common section for Flatpak jobs Avoid repeating blobs of YAML manually, and use the proper YAML mechanism to copy-paste blobs instead.
2018-04-11 16:45:29 +00:00
variables:
widget-factory: Rename to org.gtk.WidgetFactory4
2019-04-01 23:58:30 +00:00
APPID: org.gtk.WidgetFactory4
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
Update references to master in the repository
2021-11-29 22:37:49 +00:00
flatpak-main:widget-factory:
extends: .flatpak-main
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
variables:
APPID: org.gtk.WidgetFactory4
gitlabci: Build and publish docs with gitlab pages.
2018-04-30 14:12:20 +00:00
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
flatpak-manual:icon-browser:
ci: Use extends instead of YAML anchors The `extends` keyword is more readable than YAML's weird anchor syntax, and we don't have too many anchors in our job definitions anyway.
2020-05-15 12:21:45 +00:00
extends: .flatpak-manual
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
Add a flatpak manifest for org.gtk.IconBrowser4 And build it in ci.
2019-04-02 00:31:17 +00:00
variables:
APPID: org.gtk.IconBrowser4
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
Update references to master in the repository
2021-11-29 22:37:49 +00:00
flatpak-main:icon-browser:
extends: .flatpak-main
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
ci: Add manual jobs for Flatpak bundles Bundles can be useful on branches and MRs as an opt-in.
2019-04-05 18:15:11 +00:00
variables:
APPID: org.gtk.IconBrowser4
Add a flatpak manifest for org.gtk.IconBrowser4 And build it in ci.
2019-04-02 00:31:17 +00:00
flatpak: add a NodeEditor demo
2022-07-25 12:38:55 +00:00
flatpak-manual:node-editor:
extends: .flatpak-manual
needs: []
variables:
APPID: org.gtk.gtk4.NodeEditor
flatpak-main:node-editor:
extends: .flatpak-main
needs: []
variables:
APPID: org.gtk.gtk4.NodeEditor
ci: publish demo apps to the Nightly repository
2020-11-13 18:00:17 +00:00
# Publish the demo apps to the GNOME Nightly repo
# https://wiki.gnome.org/Apps/Nightly
# https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak
nightly demo:
extends: '.publish_nightly'
Update references to master in the repository
2021-11-29 22:37:49 +00:00
dependencies: ['flatpak-main:demo']
needs: ['flatpak-main:demo']
ci: publish demo apps to the Nightly repository
2020-11-13 18:00:17 +00:00
nightly factory:
extends: '.publish_nightly'
Update references to master in the repository
2021-11-29 22:37:49 +00:00
dependencies: ['flatpak-main:widget-factory']
needs: ['flatpak-main:widget-factory']
ci: publish demo apps to the Nightly repository
2020-11-13 18:00:17 +00:00
nightly icon-browser:
extends: '.publish_nightly'
Update references to master in the repository
2021-11-29 22:37:49 +00:00
dependencies: ['flatpak-main:icon-browser']
needs: ['flatpak-main:icon-browser']
ci: publish demo apps to the Nightly repository
2020-11-13 18:00:17 +00:00
flatpak: add a NodeEditor demo
2022-07-25 12:38:55 +00:00
nightly node-editor:
extends: '.publish_nightly'
dependencies: ['flatpak-main:node-editor']
needs: ['flatpak-main:node-editor']
ci: Add a static analysis job Use the Clang static analysis tool. For the time being, we're going to allow it to fail, but the plan is to fix every issue it raises.
2020-02-25 19:06:39 +00:00
static-scan:
ci: Move images into environment variables Currently we have to hunt all the `image` keys when updating the image in use for a job. We should centralise them all at the top of the file, so they are easy to update in one simple change.
2020-06-08 10:00:20 +00:00
image: $FEDORA_IMAGE
ci: Add a static analysis job Use the Clang static analysis tool. For the time being, we're going to allow it to fail, but the plan is to fix every issue it raises.
2020-02-25 19:06:39 +00:00
stage: analysis
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
ci: Add a static analysis job Use the Clang static analysis tool. For the time being, we're going to allow it to fail, but the plan is to fix every issue it raises.
2020-02-25 19:06:39 +00:00
variables:
EXTRA_MESON_FLAGS: "--buildtype=debug"
script:
ci: Redefine PATH
2022-12-14 18:35:52 +00:00
- export PATH="$HOME/.local/bin:$PATH"
ci: Install Meson in the build jobs We use the latest 0.64 even if we depend on 0.60 because of fixes in the subproject command.
2022-12-14 17:09:34 +00:00
- pip3 install --user meson~=0.64
ci: Consistently use meson subcommands meson setup: configuration meson compile: compilation meson install installation Do not use ninja directly, and do not use `meson` as a synonym for `meson setup`.
2022-12-14 17:44:27 +00:00
- meson setup ${COMMON_MESON_FLAGS} ${EXTRA_MESON_FLAGS} _scan_build
ci: Add a static analysis job Use the Clang static analysis tool. For the time being, we're going to allow it to fail, but the plan is to fix every issue it raises.
2020-02-25 19:06:39 +00:00
- ninja -C _scan_build scan-build
artifacts:
paths:
- _scan_build/meson-logs
allow_failure: true
ci: Add a build with asan Run our testsuite under asan. We do this in a separate build, since we need to turn off introspection to make the build succeed. As Michael Catanzaro pointed out, this requires a privileged runner in order to use kernel apis.
2020-07-09 02:22:31 +00:00
# Run tests with the address sanitizer. We need to turn off introspection,
# since it is incompatible with asan
asan-build:
image: $FEDORA_IMAGE
ci: Switch ASAN tests to runners tagged so
2020-07-20 14:41:46 +00:00
tags: [ asan ]
ci: Add a build with asan Run our testsuite under asan. We do this in a separate build, since we need to turn off introspection to make the build succeed. As Michael Catanzaro pointed out, this requires a privileged runner in order to use kernel apis.
2020-07-09 02:22:31 +00:00
stage: analysis
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
ci: Add a build with asan Run our testsuite under asan. We do this in a separate build, since we need to turn off introspection to make the build succeed. As Michael Catanzaro pointed out, this requires a privileged runner in order to use kernel apis.
2020-07-09 02:22:31 +00:00
variables:
script:
ci: Redefine PATH
2022-12-14 18:35:52 +00:00
- export PATH="$HOME/.local/bin:$PATH"
ci: Install Meson in the build jobs We use the latest 0.64 even if we depend on 0.60 because of fixes in the subproject command.
2022-12-14 17:09:34 +00:00
- pip3 install --user meson~=0.64
ci: Consistently use meson subcommands meson setup: configuration meson compile: compilation meson install installation Do not use ninja directly, and do not use `meson` as a synonym for `meson setup`.
2022-12-14 17:44:27 +00:00
- CC=clang meson setup --buildtype=debugoptimized -Db_sanitize=address -Db_lundef=false -Dintrospection=disabled _build
ci: Add a build with asan Run our testsuite under asan. We do this in a separate build, since we need to turn off introspection to make the build succeed. As Michael Catanzaro pointed out, this requires a privileged runner in order to use kernel apis.
2020-07-09 02:22:31 +00:00
- ninja -C _build
- .gitlab-ci/run-tests.sh _build wayland
artifacts:
paths:
- _build/meson-logs
allow_failure: true
ci: Add a separate "docs" stage Don't build the API reference on deploy; build it in a separate job, instead, so we can run it on all pipelines, and deploy it only for master.
2020-02-25 16:42:07 +00:00
reference:
ci: Update the image v32 of the image includes wayland-protocols 1.21, and other updates from Fedora 34. While we are at it, drop gtk-doc from the image, and drop the separate DOCS_IMAGE - no longer used.
2021-06-09 11:10:13 +00:00
image: $FEDORA_IMAGE
ci: Add a separate "docs" stage Don't build the API reference on deploy; build it in a separate job, instead, so we can run it on all pipelines, and deploy it only for master.
2020-02-25 16:42:07 +00:00
stage: docs
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: []
ci: Replicate the CI image scripts from GLib They are easier to use and document, and allow us to add new base images in the future without making a mess.
2020-01-29 10:01:10 +00:00
variables:
ci: Build Pango and GdkPixbuf's docs We want to publish them alongside GTK's own API reference.
2021-03-23 12:25:08 +00:00
EXTRA_MESON_FLAGS: "--buildtype=release --force-fallback-for=gdk-pixbuf,pango"
ci: Deploy the API reference on our GitLab pages Now that we can build gtk-doc as a sub-project, we can go back to publishing the API reference for the master branch every time we build it.
2020-01-29 08:16:57 +00:00
script:
ci: Redefine PATH
2022-12-14 18:35:52 +00:00
- export PATH="$HOME/.local/bin:$PATH"
ci: Install Meson in the build jobs We use the latest 0.64 even if we depend on 0.60 because of fixes in the subproject command.
2022-12-14 17:09:34 +00:00
- pip3 install --user meson~=0.64
ci: Consistently use meson subcommands meson setup: configuration meson compile: compilation meson install installation Do not use ninja directly, and do not use `meson` as a synonym for `meson setup`.
2022-12-14 17:44:27 +00:00
- meson setup ${COMMON_MESON_FLAGS} ${EXTRA_MESON_FLAGS} -Dgtk_doc=true -Dgdk-pixbuf:gtk_doc=true -Dpango:gtk_doc=true _build
ci: Update the reference job
2021-02-15 00:56:35 +00:00
- meson compile -C _build
ci: Add a separate "docs" stage Don't build the API reference on deploy; build it in a separate job, instead, so we can run it on all pipelines, and deploy it only for master.
2020-02-25 16:42:07 +00:00
- mkdir -p _reference/
ci: Update the reference job
2021-02-15 00:56:35 +00:00
- mv _build/docs/reference/gdk/gdk4/ _reference/gdk4/
- mv _build/docs/reference/gdk/gdk4-x11/ _reference/gdk4-x11/
- mv _build/docs/reference/gdk/gdk4-wayland/ _reference/gdk4-wayland/
- mv _build/docs/reference/gsk/gsk4/ _reference/gsk4/
- mv _build/docs/reference/gtk/gtk4/ _reference/gtk4/
ci: Build Pango and GdkPixbuf's docs We want to publish them alongside GTK's own API reference.
2021-03-23 12:25:08 +00:00
- mv _build/subprojects/pango/docs/Pango/ _reference/Pango/
- mv _build/subprojects/pango/docs/PangoCairo/ _reference/PangoCairo/
- mv _build/subprojects/pango/docs/PangoFc/ _reference/PangoFc/
- mv _build/subprojects/pango/docs/PangoFT2/ _reference/PangoFT2/
- mv _build/subprojects/pango/docs/PangoOT/ _reference/PangoOT/
- mv _build/subprojects/pango/docs/PangoXft/ _reference/PangoXft/
- mv _build/subprojects/gdk-pixbuf/docs/gdk-pixbuf/ _reference/gdk-pixbuf/
- mv _build/subprojects/gdk-pixbuf/docs/gdk-pixdata/ _reference/gdk-pixdata/
ci: Add a separate "docs" stage Don't build the API reference on deploy; build it in a separate job, instead, so we can run it on all pipelines, and deploy it only for master.
2020-02-25 16:42:07 +00:00
artifacts:
paths:
- _reference
ci: Trigger a pages build Do not publish the API reference directly, but trigger a CI pipeline for the docs-gtk-org branch, which will then do the publishing.
2021-07-31 16:08:56 +00:00
publish-docs:
ci: Force the fedora image for the publish-docs job Otherwise every CI runner might decide to use a different default image, and we'll end up on one that doesn't have curl.
2022-06-28 20:31:07 +00:00
image: fedora:latest
ci: Trigger a pages build Do not publish the API reference directly, but trigger a CI pipeline for the docs-gtk-org branch, which will then do the publishing.
2021-07-31 16:08:56 +00:00
stage: publish
ci: Use DAG attributes Some jobs can run out of order, as they are entirely self-contained. If we use the newly added DAG attributes, we can speed up the CI pipeline.
2020-07-27 11:44:36 +00:00
needs: ['reference']
ci: Add a separate "docs" stage Don't build the API reference on deploy; build it in a separate job, instead, so we can run it on all pipelines, and deploy it only for master.
2020-02-25 16:42:07 +00:00
script:
ci: Trigger a pages build Do not publish the API reference directly, but trigger a CI pipeline for the docs-gtk-org branch, which will then do the publishing.
2021-07-31 16:08:56 +00:00
- "curl -X POST -F token=${PAGES_TRIGGER_TOKEN} -F ref=docs-gtk-org https://gitlab.gnome.org/api/v4/projects/665/trigger/pipeline"
ci: Deploy the API reference on our GitLab pages Now that we can build gtk-doc as a sub-project, we can go back to publishing the API reference for the master branch every time we build it.
2020-01-29 08:16:57 +00:00
only:
ci: Trigger a pages build Do not publish the API reference directly, but trigger a CI pipeline for the docs-gtk-org branch, which will then do the publishing.
2021-07-31 16:08:56 +00:00
refs:
Update references to master in the repository
2021-11-29 22:37:49 +00:00
- main
Reference in New Issue Copy Permalink