AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-12-28 22:41:43 +00:00
Code Issues Projects Releases Wiki Activity
b46bfcafd1
gtk/.gitlab-ci.yml

207 lines
4.8 KiB
YAML
Raw Normal View History

Add gitlab-ci support using a prebuilt docker image
2018-02-13 16:21:18 +00:00
stages:
- 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: 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:
COMMON_MESON_FLAGS: "--fatal-meson-warnings --werror"
ci: Move backend Meson flags into a variable So we don't have to copy them around.
2020-06-08 10:35:49 +00:00
BACKEND_FLAGS: "-Dx11-backend=true -Dwayland-backend=true -Dbroadway-backend=true -Dvulkan=yes"
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_TEST_TIMEOUT_MULTIPLIER: 2
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
FEDORA_IMAGE: "registry.gitlab.gnome.org/gnome/gtk/fedora:v17"
FLATPAK_IMAGE: "registry.gitlab.gnome.org/gnome/gnome-runtime-images/gnome:master"
DOCS_IMAGE: "registry.gitlab.gnome.org/gnome/gtk/fedora-docs:v19"
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 .pre phase We want the style checks running at the start of the CI pipeline, no need to have a specific phase for it.
2020-02-25 17:57:46 +00:00
stage: .pre
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: 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"
- "${CI_PROJECT_DIR}/_build/report-wayland.xml"
- "${CI_PROJECT_DIR}/_build/report-broadway.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_PROJECT_DIR}/_build/testsuite/gsk/compare/*/*/*.png"
- "${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"
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/
fedora-x86_64:
extends: .build-fedora-default
stage: build
variables:
EXTRA_MESON_FLAGS: "--buildtype=debug --default-library=both"
script:
ci: Move backend Meson flags into a variable So we don't have to copy them around.
2020-06-08 10:35:49 +00:00
- meson ${COMMON_MESON_FLAGS} ${EXTRA_MESON_FLAGS} ${BACKEND_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
-Dprofiler=true
_build
- ninja -C _build
- .gitlab-ci/run-tests.sh _build x11
- .gitlab-ci/run-tests.sh _build wayland
- .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
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: Move backend Meson flags into a variable So we don't have to copy them around.
2020-06-08 10:35:49 +00:00
- meson ${COMMON_MESON_FLAGS} ${EXTRA_MESON_FLAGS} ${BACKEND_FLAGS}
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
_build
- ninja -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: 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:
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
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"
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: 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
# Only build Flatpak bundles automatically on master
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-master:
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:
- master
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 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-master: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-master
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 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-master: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-master
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
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-master: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-master
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
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
variables:
EXTRA_MESON_FLAGS: "--buildtype=debug"
script:
- meson ${COMMON_MESON_FLAGS} ${EXTRA_MESON_FLAGS} _scan_build
- ninja -C _scan_build scan-build
artifacts:
paths:
- _scan_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: 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: $DOCS_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: 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: 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
- meson ${COMMON_MESON_FLAGS} ${EXTRA_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
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/
- mv _build/docs/reference/gdk/html/ _reference/gdk/
- mv _build/docs/reference/gsk/html/ _reference/gsk/
- mv _build/docs/reference/gtk/html/ _reference/gtk/
artifacts:
paths:
- _reference
pages:
stage: deploy
script:
- mv _reference/ public/
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
artifacts:
paths:
- public
only:
- master
Reference in New Issue Copy Permalink