AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
70c8cfa480
gtk2/.gitlab-ci.yml

83 lines
1.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 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
gitlabci: Build and publish docs with gitlab pages.
2018-04-30 14:12:20 +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/
fedora-x86_64:
ci: move the docker image to gitlab.gnome.org
2018-04-17 17:09:16 +00:00
image: registry.gitlab.gnome.org/gnome/gtk/master:v1
Add gitlab-ci support using a prebuilt docker image
2018-02-13 16:21:18 +00:00
stage: build
script:
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
- bash -x ./.gitlab-ci/test-docker.sh
artifacts:
when: on_failure
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"
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
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: 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
image: registry.gitlab.com/alatiera/gnome-nightly-oci/gnome-master:latest
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}"
flatpak:demo:
variables:
APPID: org.gtk.Demo
<<: *flatpak-defaults
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: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:
APPID: org.gtk.WidgetFactory
<<: *flatpak-defaults
gitlabci: Build and publish docs with gitlab pages.
2018-04-30 14:12:20 +00:00
pages:
image: registry.gitlab.gnome.org/gnome/gtk/master:v1
stage: deploy
script:
- meson -Ddocumentation=true _build .
- ninja -C _build
- 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