AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-11-09 10:20:07 +00:00
Code Issues Projects Releases Wiki Activity
f51ceb142b
gtk/.gitlab-ci.yml

186 lines
4.5 KiB
YAML
Raw Normal View History

Add gitlab-ci support using a prebuilt docker image
2018-02-13 16:21:18 +00:00
stages:
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
- style-check
Add gitlab-ci support using a prebuilt docker image
2018-02-13 16:21:18 +00:00
- build
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
- flatpak
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
- 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:
COMMON_MESON_FLAGS: "--fatal-meson-warnings --werror"
MESON_TEST_TIMEOUT_MULTIPLIER: 2
ci: Disable ccache
2020-01-29 10:45:33 +00:00
G_MESSAGES_DEBUG: "all"
CCACHE_DISABLE: "true"
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
image: registry.gitlab.gnome.org/gnome/gtk/fedora:v13
stage: style-check
allow_failure: true
script:
- .gitlab-ci/run-style-check-diff.sh
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
fedora-x86_64:
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
image: registry.gitlab.gnome.org/gnome/gtk/fedora:v13
Add gitlab-ci support using a prebuilt docker image
2018-02-13 16:21:18 +00:00
stage: build
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
variables:
ci: Remove static build job Now that we figured out why the build was failing on Fedora when the profiling code was enabled, we can go back to building both shared and static libraries by default.
2020-01-29 11:23:06 +00:00
EXTRA_MESON_FLAGS: "--buildtype=debug --default-library=both"
Add gitlab-ci support using a prebuilt docker image
2018-02-13 16:21:18 +00:00
script:
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
- meson ${COMMON_MESON_FLAGS} ${EXTRA_MESON_FLAGS}
-Dx11-backend=true
-Dwayland-backend=true
-Dbroadway-backend=true
-Dvulkan=yes
-Dprofiler=true
_build
- ninja -C _build
- .gitlab-ci/run-tests.sh _build
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: 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
- "${CI_PROJECT_DIR}/_build/report.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: 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
- "${CI_PROJECT_DIR}/_build/report.xml"
ci: Add an HTML report generator The JUnit cover report is useful, but only up to a point; for instance, it's not used unless it's part of a merge request. This means you don't get a report if you're pushing to a branch that does not have an MR open. With a simple Python script and some minimal templating, we can generate an HTML report from the "I Can't Believe it's not JSON™" log that Meson produces, and keep it as a CI artifact.
2019-04-13 13:11:30 +00:00
- "${CI_PROJECT_DIR}/_build/report.html"
ci: Cache the reftest artifacts Keeping the reftest output images as artifacts of a job allows us to browse them and download them straight from GitLab.
2019-04-12 19:58:29 +00:00
- "${CI_PROJECT_DIR}/_build/testsuite/reftests/output/*.png"
Save gsk output from ci
2019-06-03 01:06:31 +00:00
- "${CI_PROJECT_DIR}/_build/testsuite/gsk/compare/*/*.png"
ci: Save syscap files from performance tests They might become useful at some point.
2020-01-22 20:55:31 +00:00
- "${CI_PROJECT_DIR}/_build/testsuite/css/output/*.syscap"
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"
<<: *cache-paths
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: 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
image: registry.gitlab.gnome.org/gnome/gtk/fedora:v13
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
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:
- meson ${COMMON_MESON_FLAGS} ${EXTRA_MESON_FLAGS}
-Dx11-backend=true
-Dwayland-backend=true
-Dbroadway-backend=true
-Dvulkan=yes
_build
- ninja -C _build
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
- .gitlab-ci/run-tests.sh _build
ci: Allow release job to fail We need to investigate release-specific failures, and possibly fix our test suite to deal with debug-specific poking through the internal state. For the time being, allow the release job to fail, but this is strictly a temporary measure.
2020-02-11 15:12:14 +00:00
allow_failure: true
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
artifacts:
when: always
reports:
junit:
- "${CI_PROJECT_DIR}/_build/report.xml"
name: "gtk-${CI_COMMIT_REF_NAME}"
paths:
- "${CI_PROJECT_DIR}/_build/meson-logs"
- "${CI_PROJECT_DIR}/_build/report.xml"
ci: Generate the report for the release builds We are going to need to hide the report generation into the test runner script, as we want the job to produce the reports even in case of failure, instead of bailing out immediately.
2020-01-29 13:36:23 +00:00
- "${CI_PROJECT_DIR}/_build/report.html"
- "${CI_PROJECT_DIR}/_build/testsuite/reftests/output/*.png"
- "${CI_PROJECT_DIR}/_build/testsuite/gsk/compare/*/*.png"
- "${CI_PROJECT_DIR}/_build/testsuite/css/output/*.syscap"
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
cache:
key: "$CI_JOB_NAME"
<<: *cache-paths
Try building static libs on CI
2019-11-11 19:11:16 +00:00
gitlab-ci: Add a 32bit mingw build
2018-04-06 16:15:38 +00:00
.mingw-defaults: &mingw-defaults
stage: build
tags:
- win32
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:
key: "%CI_JOB_NAME%"
<<: *cache-paths
gitlab-ci: Add a 32bit mingw build
2018-04-06 16:15:38 +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
msys2-mingw32:
gitlab-ci: Add a 32bit mingw build
2018-04-06 16:15:38 +00:00
variables:
MSYSTEM: "MINGW32"
CHERE_INVOKING: "yes"
<<: *mingw-defaults
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
.flatpak-defaults: &flatpak-defaults
ci: Update the image for the Flatpak jobs The gnome-nightly-oci registry was moved to gitlab.gnome.org, so we need to change the image we use when building Flatpak bundles in our CI pipeline.
2018-07-04 17:32:59 +00:00
image: registry.gitlab.gnome.org/gnome/gnome-runtime-images/gnome:master
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
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: 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
.flatpak-manual: &flatpak-manual
<<: *flatpak-defaults
when: manual
# Only build Flatpak bundles automatically on master
.flatpak-master: &flatpak-master
<<: *flatpak-defaults
only:
- master
flatpak-manual:demo:
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
<<: *flatpak-manual
flatpak-master:demo:
variables:
APPID: org.gtk.Demo4
<<: *flatpak-master
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 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
<<: *flatpak-manual
flatpak-master:widget-factory:
variables:
APPID: org.gtk.WidgetFactory4
<<: *flatpak-master
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:
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
<<: *flatpak-manual
flatpak-master:icon-browser:
variables:
APPID: org.gtk.IconBrowser4
<<: *flatpak-master
Add a flatpak manifest for org.gtk.IconBrowser4 And build it in ci.
2019-04-02 00:31:17 +00:00
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
pages:
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
image: registry.gitlab.gnome.org/gnome/gtk/fedora:v13
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
stage: deploy
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:
EXTRA_MESON_FLAGS: "--buildtype=release"
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: 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
- meson ${COMMON_MESON_FLAGS} -Dgtk_doc=true _build
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
- ninja -C _build gdk4-doc gsk4-doc gtk4-doc
- mkdir -p public/
- mv _build/docs/reference/gtk/html/ public/gtk/
- mv _build/docs/reference/gdk/html/ public/gdk/
- mv _build/docs/reference/gsk/html/ public/gsk/
artifacts:
paths:
- public
only:
- master
Reference in New Issue Copy Permalink