dnrops
/
gimp
mirror of https://github.com/GNOME/gimp.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gimp/.gitlab-ci.yml

951 lines
33 KiB
YAML
Raw Normal View History

gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Default commit CI should only run the following pipelines:
gitlab-ci: native (MSYS2) Win32 32/64 builds only on schedules. Having them at each commit is counter-productive, first because these builds take so long and second because there seems to be quite few Windows runners. So we end up constantly waiting for CI jobs from previous commits (so we are just constantly waiting). This is resource over-usage. So instead, I'll just set this in scheduled jobs. For release preparation though, we'll have to set up a workflow later to trigger these jobs off-schedule/on-demand (I can see there is a Gitlab interface to do this), but this can wait for when the installer is fully generated by the CI anyway.
2021-05-13 23:47:03 +08:00
# - Linux autotools and meson (base & fast)
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# - Win64 crossbuild (base & fast)
# Scheduled CI ($CI_PIPELINE_SOURCE == "schedule") will run regularly:
gitlab-ci: native (MSYS2) Win32 32/64 builds only on schedules. Having them at each commit is counter-productive, first because these builds take so long and second because there seems to be quite few Windows runners. So we end up constantly waiting for CI jobs from previous commits (so we are just constantly waiting). This is resource over-usage. So instead, I'll just set this in scheduled jobs. For release preparation though, we'll have to set up a workflow later to trigger these jobs off-schedule/on-demand (I can see there is a Gitlab interface to do this), but this can wait for when the installer is fully generated by the CI anyway.
2021-05-13 23:47:03 +08:00
# - Win 32/64 native builds (base but slow)
# - Win32 crossbuilds (rare usefulness)
# - Linux CLang (rare usefulness)
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# - cppcheck (static code analysis)
gitlab-ci: create a GIMP_CI_FLATPAK Gitlab variable to trigger the… … flatpak build and publishing. Same as we are doing for other build pipelines. This allows finer manual builds (not just "on schedules").
2021-05-27 01:35:19 +08:00
# - Flatpak build (slow and doesn't need constant publishing)
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Releases ($CI_COMMIT_TAG != null) should run only:
gitlab-ci: native (MSYS2) Win32 32/64 builds only on schedules. Having them at each commit is counter-productive, first because these builds take so long and second because there seems to be quite few Windows runners. So we end up constantly waiting for CI jobs from previous commits (so we are just constantly waiting). This is resource over-usage. So instead, I'll just set this in scheduled jobs. For release preparation though, we'll have to set up a workflow later to trigger these jobs off-schedule/on-demand (I can see there is a Gitlab interface to do this), but this can wait for when the installer is fully generated by the CI anyway.
2021-05-13 23:47:03 +08:00
# - Linux autotools (distcheck source tarball)
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# - Win 32/64 native builds (Windows installer creation)
#
# To force step-specific pipelines without waiting for commits and/or
# pipelines, these are the variable you should set:
# - GIMP_CI_AUTOTOOLS: trigger the autotools/gcc build.
# - GIMP_CI_MESON_GCC: trigger the meson/gcc build.
# - GIMP_CI_MESON_CLANG: trigger the meson/clang build.
# - GIMP_CI_CROSSROAD_WIN32: trigger the crossroad/meson build for Win 32-bit.
# - GIMP_CI_CROSSROAD_WIN64: trigger the crossroad/meson build for Win 64-bit.
# - GIMP_CI_MSYS2_WIN32: trigger the native MSYS2 build for Win 32-bit.
# - GIMP_CI_MSYS2_WIN64: trigger the native MSYS2 build for Win 64-bit.
# - GIMP_CI_WIN_INSTALLER: trigger both native MSYS2 builds then creates Windows installer.
# - GIMP_CI_SOURCES: trigger the autotools/gcc build and the source tarball job.
# - GIMP_CI_CPPCHECK: trigger cppcheck static analysis.
gitlab-ci: create a GIMP_CI_FLATPAK Gitlab variable to trigger the… … flatpak build and publishing. Same as we are doing for other build pipelines. This allows finer manual builds (not just "on schedules").
2021-05-27 01:35:19 +08:00
# - GIMP_CI_FLATPAK: trigger the nightly flatpak build and publishing.
gitlab-ci: add a new GIMP_CI_RASTER_ICONS to test raster icon build. Since this is probably much less tested than the default vector icon case, any bug there might go unseen for some time. So let's add a new pipeline to check this. I make so this pipeline is not actually run on every commit (i.e. manually only), then I'll just add a scheduled pipeline to check the non-vector icon case at regular intervals. This pipeline also test the icon-list.mk files are not outdated.
2022-01-27 23:32:02 +08:00
# - GIMP_CI_RASTER_ICONS: trigger the autotools and meson builds without vector icons.
gitlab-ci: native (MSYS2) Win32 32/64 builds only on schedules. Having them at each commit is counter-productive, first because these builds take so long and second because there seems to be quite few Windows runners. So we end up constantly waiting for CI jobs from previous commits (so we are just constantly waiting). This is resource over-usage. So instead, I'll just set this in scheduled jobs. For release preparation though, we'll have to set up a workflow later to trigger these jobs off-schedule/on-demand (I can see there is a Gitlab interface to do this), but this can wait for when the installer is fully generated by the CI anyway.
2021-05-13 23:47:03 +08:00
ci: Enable nightly flatpak builds To get a nightly flatpak, GNOME project offers a CI template[0] that can be extended instead of having to define everything from scratch. At the core is the "flatpak" job that tries to build the flatpak. If the build finishes succesfully, the result should be available as a CI artifact as a flatpak bundle. The app id is the same as on Flathub. Another part is the "flatpak-nightly" job that publishes the flatpak if the build succeeded. Without this job, the bundle stays only temporarily. This job can and should only be run on the "master" branch. This jobs is started only when the "flatpak" job finishes successfully. Both jobs can be triggered only thorugh schedules[1]. To finish the flatpak nightlies setup, a schedule needs to be set. [0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak [1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
2020-09-07 23:49:37 +08:00
include: 'https://gitlab.gnome.org/GNOME/citemplates/raw/master/flatpak/flatpak_ci_initiative.yml'
gitlab-ci: port our main CI to Debian testing. The old custom ArchLinux got broken (apparently by some package signature verification which fails, and obviously we don't want to bypass these for security reasons). I took the opportunity to port to Debian testing because this is GIMP's base distribution for support (basically dependency versions must be in Debian testing) so it makes sense that our CI is based off it as well. Note though that I am not against additional CI tests so if someone absolutely wants to get the Archlinux-based CI back and thinks it gets us some additional worthy test, feel free to fix whatever was broken then we may add it back (having both Debian testing and Archlinux CI).
2020-01-02 02:57:06 +08:00
image: debian:testing
refactoring of the gitlab-ci.yml
2019-08-21 19:54:38 +08:00
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
stages:
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
- prepare
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
- dependencies
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
- gimp
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
- packaging
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
- distribution
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
- analysis
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
variables:
gitlab-ci: set GIT_DEPTH to 1. We don't need to pull 5 commits of history. Only the HEAD of the selected branch is needed. Also define it globally rather than re-defining it in every job to the same value.
2019-10-02 02:36:09 +08:00
GIT_DEPTH: "1"
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
INSTALL_DIR: "_install"
refactoring of the gitlab-ci.yml
2019-08-21 19:54:38 +08:00
INSTALL_PREFIX: "${CI_PROJECT_DIR}/${INSTALL_DIR}"
app: CI cache now configured in GNOME gitlab. Let's reimplement some caching of packages for Debian apt and crossroad. Hopefully it should speed up subsequent builds.
2020-05-29 01:51:50 +08:00
APT_CACHE: "${CI_PROJECT_DIR}/apt-cache"
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
## prepare docker images ##
build-image:
gitlab-ci: add Win 32-bit and Linux Clang builds to schedules. These are interesting and may find very specific bugs from time to time, but the usefulness is rare enough not to warrant to run at each commits. This is just a waste of resources. For scheduling finesse (in case we want to separate these in separate scheduling), also rely on the existence of variables during scheduling. Finally make sure that the non-scheduled builds are not run in schedule pipelines (they are already run far enough).
2021-05-06 21:38:23 +08:00
rules:
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
# On commits and merge requests.
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
- if: '$CI_PIPELINE_SOURCE == "push"'
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_AUTOTOOLS != null'
- if: '$GIMP_CI_SOURCES != null'
- if: '$GIMP_CI_MESON_GCC != null'
- if: '$GIMP_CI_MESON_CLANG != null'
gitlab-ci: add a new GIMP_CI_RASTER_ICONS to test raster icon build. Since this is probably much less tested than the default vector icon case, any bug there might go unseen for some time. So let's add a new pipeline to check this. I make so this pipeline is not actually run on every commit (i.e. manually only), then I'll just add a scheduled pipeline to check the non-vector icon case at regular intervals. This pipeline also test the icon-list.mk files are not outdated.
2022-01-27 23:32:02 +08:00
- if: '$GIMP_CI_RASTER_ICONS != null'
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
stage: prepare
variables:
GIT_STRATEGY: none
cache: {}
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
script:
- mkdir -p /kaniko/.docker
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- echo "FROM debian:testing" > Dockerfile
- echo "RUN apt-get update" >> Dockerfile
- echo "RUN apt-get install -y --no-install-recommends \\" >> Dockerfile
gitlab-ci: build the specific Python and gjs doc with g-ir-doc.
2022-03-27 03:10:13 +08:00
- echo "at-spi2-core build-essential desktop-file-utils ffmpeg ghostscript git glib-networking gobject-introspection graphviz graphviz-dev hicolor-icon-theme intltool iso-codes libappstream-glib-dev libbz2-dev libdbus-glib-1-dev libexif-dev libgexiv2-dev libgirepository1.0-dev libgtk-3-bin libgtk-3-dev libgudev-1.0-dev libjson-glib-dev liblcms2-dev liblzma-dev libmng-dev libmypaint-dev libopenexr-dev libpoppler-glib-dev libraw-dev libraw20 librsvg2-dev libspiro-dev libsuitesparse-dev libtiff-dev libtiff5-dev libtool libumfpack5 libwebp-dev libwmf-dev libxmu-dev libxpm-dev luajit meson mypaint-brushes poppler-data python3 python3-pip valac xauth xsltproc xvfb yelp-tools" >> Dockerfile
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
- echo "RUN pip3 install --no-cache-dir gi-docgen jinja2 Markdown markupsafe pygments toml typogrify" >> Dockerfile
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:build-debian-latest --cache=true --cache-ttl=120h
build-image-win64:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On commits except tags.
- if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_TAG == null'
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
# On merge requests.
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_CROSSROAD_WIN64 != null'
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
stage: prepare
variables:
GIT_STRATEGY: none
cache: {}
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
script:
- mkdir -p /kaniko/.docker
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- echo "FROM debian:testing" > Dockerfile
- echo "RUN apt-get update" >> Dockerfile
- echo "RUN apt-get install -y --no-install-recommends \\" >> Dockerfile
gitlab-ci: install native librsvg in a cross-build environment. Needed to construct the icons.
2022-02-01 06:06:34 +08:00
- echo "build-essential cmake cpio g++-mingw-w64-x86-64 gcc-mingw-w64-x86-64 git intltool libgdk-pixbuf2.0-dev libglib2.0-bin librsvg2-dev meson pkg-config python3 python3-distutils python3-docutils python3-pip rpm xsltproc" >> Dockerfile
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:build-win64-latest --cache=true --cache-ttl=120h
build-image-win32:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_CROSSROAD_WIN32 != null'
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
stage: prepare
variables:
GIT_STRATEGY: none
cache: {}
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
script:
- mkdir -p /kaniko/.docker
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- echo "FROM debian:testing" > Dockerfile
- echo "RUN apt-get update" >> Dockerfile
- echo "RUN apt-get install -y --no-install-recommends \\" >> Dockerfile
gitlab-ci: install native librsvg in a cross-build environment. Needed to construct the icons.
2022-02-01 06:06:34 +08:00
- echo "build-essential cpio g++-mingw-w64-i686 gcc-mingw-w64-i686 git intltool libgdk-pixbuf2.0-dev libglib2.0-bin librsvg2-dev meson pkg-config python3 python3-distutils python3-docutils python3-pip rpm xsltproc" >> Dockerfile
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:build-win32-latest --cache=true --cache-ttl=120h
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
## GNU/Linux 64-bit CIs (Debian testing) ##
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
deps-debian:
gitlab-ci: add Win 32-bit and Linux Clang builds to schedules. These are interesting and may find very specific bugs from time to time, but the usefulness is rare enough not to warrant to run at each commits. This is just a waste of resources. For scheduling finesse (in case we want to separate these in separate scheduling), also rely on the existence of variables during scheduling. Finally make sure that the non-scheduled builds are not run in schedule pipelines (they are already run far enough).
2021-05-06 21:38:23 +08:00
rules:
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
# On commits and merge requests.
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
- if: '$CI_PIPELINE_SOURCE == "push"'
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_AUTOTOOLS != null'
- if: '$GIMP_CI_SOURCES != null'
- if: '$GIMP_CI_MESON_GCC != null'
- if: '$GIMP_CI_MESON_CLANG != null'
gitlab-ci: add a new GIMP_CI_RASTER_ICONS to test raster icon build. Since this is probably much less tested than the default vector icon case, any bug there might go unseen for some time. So let's add a new pipeline to check this. I make so this pipeline is not actually run on every commit (i.e. manually only), then I'll just add a scheduled pipeline to check the non-vector icon case at regular intervals. This pipeline also test the icon-list.mk files are not outdated.
2022-01-27 23:32:02 +08:00
- if: '$GIMP_CI_RASTER_ICONS != null'
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
stage: dependencies
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
image: $CI_REGISTRY_IMAGE:build-debian-latest
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
cache:
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
paths:
app: CI cache now configured in GNOME gitlab. Let's reimplement some caching of packages for Debian apt and crossroad. Hopefully it should speed up subsequent builds.
2020-05-29 01:51:50 +08:00
- apt-cache
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
artifacts:
.gitlab-ci.yml: change artifact expiry to 2 hours for dependencies and 1 day for MS Windows builds
2020-05-04 00:29:43 +08:00
expire_in: 2 hours
gitlab-ci: improve artifacts settings. First replace the "when: on_failure" rule by a "when: always". We indeed always want to get log artifact so that we can study a build if necessary (neither only on failure nor on success; really on all cases, since even an apparently successful build may have issues we might want to diagnose). Also expire all artifacts at 1 week (it seems the default on GNOME's Gitlab is 4 weeks; we don't need to keep these so long. Even a few days might be enough actually). As for the artifacts contents, keep the build dirs rather than the install dirs. Build dirs allow to check configuration logs and other kind of logs which are the most useful when diagnosing a failed build. Now install dirs are also interesting. Maybe we should provide them again at some point. We'll see. For now I comment them out. Still keep the install dir for dependencies though, since it seems this is how data are passed from one job to another. Note that ideally we would like to provide different artifacts depending on failure or success but apparently this is currently not possible. See: https://gitlab.com/gitlab-org/gitlab/issues/18744 Also not sure why for GIMP, the CI was only keeping the build app/tests/ directory. We should really keep the whole dir.
2019-10-02 00:36:07 +08:00
when: always
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
paths:
refactoring of the gitlab-ci.yml
2019-08-21 19:54:38 +08:00
- "${INSTALL_DIR}"
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
- _babl/_build
gitlab-ci: improve artifacts settings. First replace the "when: on_failure" rule by a "when: always". We indeed always want to get log artifact so that we can study a build if necessary (neither only on failure nor on success; really on all cases, since even an apparently successful build may have issues we might want to diagnose). Also expire all artifacts at 1 week (it seems the default on GNOME's Gitlab is 4 weeks; we don't need to keep these so long. Even a few days might be enough actually). As for the artifacts contents, keep the build dirs rather than the install dirs. Build dirs allow to check configuration logs and other kind of logs which are the most useful when diagnosing a failed build. Now install dirs are also interesting. Maybe we should provide them again at some point. We'll see. For now I comment them out. Still keep the install dir for dependencies though, since it seems this is how data are passed from one job to another. Note that ideally we would like to provide different artifacts depending on failure or success but apparently this is currently not possible. See: https://gitlab.com/gitlab-org/gitlab/issues/18744 Also not sure why for GIMP, the CI was only keeping the build app/tests/ directory. We should really keep the whole dir.
2019-10-02 00:36:07 +08:00
- _gegl/_build
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
before_script:
gitlab-ci: port our main CI to Debian testing. The old custom ArchLinux got broken (apparently by some package signature verification which fails, and obviously we don't want to bypass these for security reasons). I took the opportunity to port to Debian testing because this is GIMP's base distribution for support (basically dependency versions must be in Debian testing) so it makes sense that our CI is based off it as well. Note though that I am not against additional CI tests so if someone absolutely wants to get the Archlinux-based CI back and thinks it gets us some additional worthy test, feel free to fix whatever was broken then we may add it back (having both Debian testing and Archlinux CI).
2020-01-02 02:57:06 +08:00
- git clone --depth=${GIT_DEPTH} https://gitlab.gnome.org/GNOME/babl.git _babl
refactoring of the gitlab-ci.yml
2019-08-21 19:54:38 +08:00
- git clone --depth=${GIT_DEPTH} https://gitlab.gnome.org/GNOME/gegl.git _gegl
gitlab-ci: port our main CI to Debian testing. The old custom ArchLinux got broken (apparently by some package signature verification which fails, and obviously we don't want to bypass these for security reasons). I took the opportunity to port to Debian testing because this is GIMP's base distribution for support (basically dependency versions must be in Debian testing) so it makes sense that our CI is based off it as well. Note though that I am not against additional CI tests so if someone absolutely wants to get the Archlinux-based CI back and thinks it gets us some additional worthy test, feel free to fix whatever was broken then we may add it back (having both Debian testing and Archlinux CI).
2020-01-02 02:57:06 +08:00
- export PKG_CONFIG_PATH="${INSTALL_PREFIX}/lib/pkgconfig"
- export PKG_CONFIG_PATH="${INSTALL_PREFIX}/lib/`gcc -print-multiarch`/pkgconfig/:$PKG_CONFIG_PATH"
- export LD_LIBRARY_PATH="${INSTALL_PREFIX}/lib:${LD_LIBRARY_PATH}"
- export LD_LIBRARY_PATH="${INSTALL_PREFIX}/lib/`gcc -print-multiarch`:$LD_LIBRARY_PATH"
- export XDG_DATA_DIRS="${INSTALL_PREFIX}/share:/usr/local/share:/usr/share"
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
script:
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
- cd _babl
- meson -Dprefix="${INSTALL_PREFIX}" _build
- ninja -C _build
- ninja -C _build install
- cd ../_gegl
refactoring of the gitlab-ci.yml
2019-08-21 19:54:38 +08:00
- meson --prefix="${INSTALL_PREFIX}" _build
build: .gitlab-ci.yml: GEGL is switching to meson exclusively
2019-08-17 03:30:57 +08:00
- ninja -C _build
- ninja -C _build install
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
needs: ["build-image"]
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
.gimp-debian-base:
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
stage: gimp
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
image: $CI_REGISTRY_IMAGE:build-debian-latest
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
dependencies:
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
- deps-debian
app: CI cache now configured in GNOME gitlab. Let's reimplement some caching of packages for Debian apt and crossroad. Hopefully it should speed up subsequent builds.
2020-05-29 01:51:50 +08:00
cache:
paths:
- apt-cache
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
artifacts:
.gitlab-ci.yml: expire all dependencies in 2 hours, and all builds in 1 day
2020-05-09 19:19:18 +08:00
expire_in: 1 days
gitlab-ci: improve artifacts settings. First replace the "when: on_failure" rule by a "when: always". We indeed always want to get log artifact so that we can study a build if necessary (neither only on failure nor on success; really on all cases, since even an apparently successful build may have issues we might want to diagnose). Also expire all artifacts at 1 week (it seems the default on GNOME's Gitlab is 4 weeks; we don't need to keep these so long. Even a few days might be enough actually). As for the artifacts contents, keep the build dirs rather than the install dirs. Build dirs allow to check configuration logs and other kind of logs which are the most useful when diagnosing a failed build. Now install dirs are also interesting. Maybe we should provide them again at some point. We'll see. For now I comment them out. Still keep the install dir for dependencies though, since it seems this is how data are passed from one job to another. Note that ideally we would like to provide different artifacts depending on failure or success but apparently this is currently not possible. See: https://gitlab.com/gitlab-org/gitlab/issues/18744 Also not sure why for GIMP, the CI was only keeping the build app/tests/ directory. We should really keep the whole dir.
2019-10-02 00:36:07 +08:00
when: always
gitlab-ci: name the distribution artifacts and small build-deps.sh fix. This should give a nice name to distribution archives so that they are not all called `artifacts.zip`. Names will better describe their contents (target OS or source and short commit hash, because for CI builds, it's important to know which commit is being tested). Also replace CI_COMMIT_REF_NAME in other artifact names by CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in branch names), only the part after the last slash is used for archive naming. Finally immediately exits from dependency build with error code (!= 0) if `crossroad install` command failed.
2020-10-04 00:04:27 +08:00
name: "app-build-${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
paths:
gitlab-ci: improve artifacts settings. First replace the "when: on_failure" rule by a "when: always". We indeed always want to get log artifact so that we can study a build if necessary (neither only on failure nor on success; really on all cases, since even an apparently successful build may have issues we might want to diagnose). Also expire all artifacts at 1 week (it seems the default on GNOME's Gitlab is 4 weeks; we don't need to keep these so long. Even a few days might be enough actually). As for the artifacts contents, keep the build dirs rather than the install dirs. Build dirs allow to check configuration logs and other kind of logs which are the most useful when diagnosing a failed build. Now install dirs are also interesting. Maybe we should provide them again at some point. We'll see. For now I comment them out. Still keep the install dir for dependencies though, since it seems this is how data are passed from one job to another. Note that ideally we would like to provide different artifacts depending on failure or success but apparently this is currently not possible. See: https://gitlab.com/gitlab-org/gitlab/issues/18744 Also not sure why for GIMP, the CI was only keeping the build app/tests/ directory. We should really keep the whole dir.
2019-10-02 00:36:07 +08:00
- _build
#- "${INSTALL_DIR}"
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
before_script:
gitlab-ci: port our main CI to Debian testing. The old custom ArchLinux got broken (apparently by some package signature verification which fails, and obviously we don't want to bypass these for security reasons). I took the opportunity to port to Debian testing because this is GIMP's base distribution for support (basically dependency versions must be in Debian testing) so it makes sense that our CI is based off it as well. Note though that I am not against additional CI tests so if someone absolutely wants to get the Archlinux-based CI back and thinks it gets us some additional worthy test, feel free to fix whatever was broken then we may add it back (having both Debian testing and Archlinux CI).
2020-01-02 02:57:06 +08:00
- export PKG_CONFIG_PATH="${INSTALL_PREFIX}/lib/pkgconfig:${INSTALL_PREFIX}/share/pkgconfig"
- export PKG_CONFIG_PATH="${INSTALL_PREFIX}/lib/`gcc -print-multiarch`/pkgconfig/:$PKG_CONFIG_PATH"
- export PKG_CONFIG_PATH="${INSTALL_PREFIX}/share/`gcc -print-multiarch`/pkgconfig/:$PKG_CONFIG_PATH"
- export LD_LIBRARY_PATH="${INSTALL_PREFIX}/lib:${LD_LIBRARY_PATH}"
- export LD_LIBRARY_PATH="${INSTALL_PREFIX}/lib/`gcc -print-multiarch`:$LD_LIBRARY_PATH"
- export XDG_DATA_DIRS="${INSTALL_PREFIX}/share:/usr/local/share:/usr/share"
- export PATH="${INSTALL_PREFIX}/bin:$PATH"
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
needs: ["deps-debian"]
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
gimp-distcheck-debian:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
rules:
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
# On commits and merge requests.
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
- if: '$CI_PIPELINE_SOURCE == "push"'
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_AUTOTOOLS != null'
- if: '$GIMP_CI_SOURCES != null'
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
extends: .gimp-debian-base
gitlab-ci: add a distcheck step on master too. Similar to the distcheck step only contributed by schumaml on gimp-2-10.
2020-08-03 08:27:29 +08:00
script:
- mkdir _build
- cd _build
- ../autogen.sh
--prefix="${INSTALL_PREFIX}"
--enable-debug
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
--enable-gi-docgen
gitlab-ci, build: --enable-windows-installer also on Linux. By enabling this option on Linux, not only will the installer language file be generated, but the `make check` will also now validate that the lang list is consistent with existing gettext files (see commit 8a42c6ccc2). So it's useful information to know this for instance as soon as some translators add a new localization. Also oppositely remove the option on the MSYS2 native Windows 32-bit build. For Windows, we only need this option once, as we use the language files generated by the 64-bit build.
2021-05-20 08:55:54 +08:00
--enable-windows-installer
gitlab-ci: add a distcheck step on master too. Similar to the distcheck step only contributed by schumaml on gimp-2-10.
2020-08-03 08:27:29 +08:00
- make -j "$(nproc)"
gitlab-ci: gimp-distcheck-debian and gimp-autotools-debian redundant. We had an autotools build stopping at `make check` and a separate one for `make distcheck`. This just seems very redundant hence a waste of resources. So let's drop the job gimp-autotools-debian then add a `make check` step to gimp-distcheck-debian. Also as a side change, I move the cppcheck to being a scheduled job. It's not such resource intensive job, nor did it take much time, yet it's not like we use this information constantly. Moreover it never fails anyway (so it's not like it gives much information on a per-commit basis, unless we explicitly look into the resulting files) and with the ability to run custom jobs whenever we want, this is far enough if sometimes we need to generate the cppcheck analysis more frequently. The rest of the time, having 2 jobs of this a week (our current schedule) is far enough.
2021-05-15 01:56:55 +08:00
- make -j "$(nproc)" check
gitlab-ci: run distcheck with multi-jobs.
2020-08-07 21:30:05 +08:00
- make -j "$(nproc)" distcheck
gitlab-ci: add a distcheck step on master too. Similar to the distcheck step only contributed by schumaml on gimp-2-10.
2020-08-03 08:27:29 +08:00
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
gimp-meson-debian:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On commits except tags.
- if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_TAG == null'
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
# On merge requests.
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_MESON_GCC != null'
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
extends: .gimp-debian-base
Update gitlab-ci
2019-08-09 22:18:43 +08:00
script:
- meson _build
gitlab-ci: build the specific Python and gjs doc with g-ir-doc.
2022-03-27 03:10:13 +08:00
--prefix="${INSTALL_PREFIX}" -Dg-ir-doc=true
Update gitlab-ci
2019-08-09 22:18:43 +08:00
- ninja -C _build
gitlab-ci: run unit tests for meson builds. Not because they are working better than the ones in autotools, but rather because it seems they are simply barely implemented! So of course, the few tests currently there work.
2020-01-04 05:55:09 +08:00
- ninja -C _build test
gitlab-ci: build and test `meson dist`.
2022-03-19 20:51:56 +08:00
- ninja -C _build dist
Update gitlab-ci
2019-08-09 22:18:43 +08:00
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
gimp-clang-debian:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_MESON_CLANG != null'
gitlab-ci: rename the CI jobs. The Linux CI job names are too long and are not recognizable on the web GUI unless you hover the widgets with the mouse to read tooltips. Remove the "/testing" part (if people want to know exactly which Debian we use for our builds, they can always look at the script) and move left the differenciating parts (i.e. autotools/meson/clang/distcheck) so that these are visible in a glance, even when ellipsing long job names.
2020-08-06 19:21:05 +08:00
extends: .gimp-debian-base
gitlab-ci: test a CLang build.
2020-01-03 07:19:10 +08:00
variables:
CC: "clang"
CXX: "clang++"
script:
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
- mkdir -p "$APT_CACHE"
app: CI cache now configured in GNOME gitlab. Let's reimplement some caching of packages for Debian apt and crossroad. Hopefully it should speed up subsequent builds.
2020-05-29 01:51:50 +08:00
- apt-get install -y --no-install-recommends -o dir::cache::archives="$APT_CACHE"
gitlab-ci: fix recently broken CLang compilation. Fixes: > /usr/bin/ld: cannot find -lomp
2020-03-16 05:21:19 +08:00
clang libomp-dev
gitlab-ci: test a CLang build.
2020-01-03 07:19:10 +08:00
- meson _build
--prefix="${INSTALL_PREFIX}"
Issue #6257: Race condition bug in meson build. Argh! My previous commit logics was right, but should have been applied to the Windows builds (where the issue happens). That's what happens when I hack too late at night!
2021-05-20 10:32:20 +08:00
- ninja -C _build
gitlab-ci: run unit tests for meson builds. Not because they are working better than the ones in autotools, but rather because it seems they are simply barely implemented! So of course, the few tests currently there work.
2020-01-04 05:55:09 +08:00
- ninja -C _build test
gitlab-ci: test a CLang build.
2020-01-03 07:19:10 +08:00
gitlab-ci: add a new GIMP_CI_RASTER_ICONS to test raster icon build. Since this is probably much less tested than the default vector icon case, any bug there might go unseen for some time. So let's add a new pipeline to check this. I make so this pipeline is not actually run on every commit (i.e. manually only), then I'll just add a scheduled pipeline to check the non-vector icon case at regular intervals. This pipeline also test the icon-list.mk files are not outdated.
2022-01-27 23:32:02 +08:00
gimp-meson-raster-icons:
rules:
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_RASTER_ICONS != null'
extends: .gimp-debian-base
script:
- meson _build
--prefix="${INSTALL_PREFIX}"
-Dvector-icons=false
- ninja -C _build
- ninja -C _build test
gimp-autotools-raster-icons:
rules:
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_RASTER_ICONS != null'
extends: .gimp-debian-base
script:
- tools/generate-icon-makefiles.py
- diff="$(git diff)"
- if [ -n "$diff" ]; then
echo "Outdated icon-list.mk - please run tools/generate-icon-makefiles.py";
echo "$diff";
exit 1;
fi
- mkdir _build
- cd _build
- ../autogen.sh
--prefix="${INSTALL_PREFIX}"
--disable-vector-icons
- make -j "$(nproc)"
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
## WINDOWS 64-bit CI (native MSYS2) ##
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
deps-win64-native:
gitlab-ci: add Win 32-bit and Linux Clang builds to schedules. These are interesting and may find very specific bugs from time to time, but the usefulness is rare enough not to warrant to run at each commits. This is just a waste of resources. For scheduling finesse (in case we want to separate these in separate scheduling), also rely on the existence of variables during scheduling. Finally make sure that the non-scheduled builds are not run in schedule pipelines (they are already run far enough).
2021-05-06 21:38:23 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_MSYS2_WIN64 != null'
- if: '$GIMP_CI_WIN_INSTALLER != null'
gitlab-ci: add support for flatpak and Windows installer jobs in MR… … based on set labels. If the label "5. Windows Installer" is set, the MR pipeline should trigger the Windows installer pipeline as well. If the label "5. Flatpak package" is set, it should generate the flatpak (not publish it obviously, yet it can be downloaded and installed manually). This will allow us to easily test MRs and allow people to test our code before we merge it to the main branches.
2021-05-28 19:35:40 +08:00
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
stage: dependencies
gitlab-ci, build: testing native Windows build. Just an initial test to get a hang of the thing, mostly inspired from GTK gitlab-ci rules adapted to our build. All in one job (deps, babl, GEGL, GIMP itself) for now, for simplicity of debugging. We'll see later to break this into CI sub-jobs.
2021-05-02 21:43:25 +08:00
variables:
MSYSTEM: "MINGW64"
CHERE_INVOKING: "yes"
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
tags:
- win32-ps
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/build-deps-msys2.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
when: always
expire_in: 2 hours
paths:
gitlab-ci, build: construct the Windows installer from CI. Run InnoSetup in the Windows CI to build the installer from both the 32 and 64-bit builds. Current limitations: - No installer signature yet. - Dependencies will have to be checked more thoroughly. - Apart from babl and GEGL, we may want to make custom builds of any package which has a patch in build/windows/patches/ (Windows-specific patches) and build/patches/ (all platform patches). - Plug-in interpreters (Python, Lua…) don't work. This will need to be looked at in detail. Globally this first automated installer build works fine though, as I could install it in a Windows 10 VM and GIMP ran fine! So it's a first step towards fully automated releases for Windows.
2021-05-11 03:50:49 +08:00
- _install-w64
build: add aalib dependency for ASCII Art support. - Adding a patch sent to me by Sylvie Alexandre meant to help aalib build on MSYS2 for Windows 32 and 64-bit. - Additionally, add an additional patch from myself because it was still not building properly. - Also update the config.guess|sub files because the original ones (from 2001!) were just too old and not properly recognizing the host mingw system (especially the 64-bit one apparently) in the MSYS2 CI jobs of GIMP. - Finally regenerate the whole aclocal/libtoolize/autoconf/automake build system because these old files just don't play nice with recent autotools though the source files still regenerate fine (despite with some warnings, but nothing blocking). - Add crt-git dependency because libws2_32 is in there.
2021-05-16 01:40:12 +08:00
- aalib-1.4.0/_build
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
needs: []
gimp-win64-native:
gitlab-ci: add Win 32-bit and Linux Clang builds to schedules. These are interesting and may find very specific bugs from time to time, but the usefulness is rare enough not to warrant to run at each commits. This is just a waste of resources. For scheduling finesse (in case we want to separate these in separate scheduling), also rely on the existence of variables during scheduling. Finally make sure that the non-scheduled builds are not run in schedule pipelines (they are already run far enough).
2021-05-06 21:38:23 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_MSYS2_WIN64 != null'
- if: '$GIMP_CI_WIN_INSTALLER != null'
gitlab-ci: add support for flatpak and Windows installer jobs in MR… … based on set labels. If the label "5. Windows Installer" is set, the MR pipeline should trigger the Windows installer pipeline as well. If the label "5. Flatpak package" is set, it should generate the flatpak (not publish it obviously, yet it can be downloaded and installed manually). This will allow us to easily test MRs and allow people to test our code before we merge it to the main branches.
2021-05-28 19:35:40 +08:00
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
gitlab-ci, build: testing native Windows build. Just an initial test to get a hang of the thing, mostly inspired from GTK gitlab-ci rules adapted to our build. All in one job (deps, babl, GEGL, GIMP itself) for now, for simplicity of debugging. We'll see later to break this into CI sub-jobs.
2021-05-02 21:43:25 +08:00
stage: gimp
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
variables:
MSYSTEM: "MINGW64"
CHERE_INVOKING: "yes"
gitlab-ci, build: testing native Windows build. Just an initial test to get a hang of the thing, mostly inspired from GTK gitlab-ci rules adapted to our build. All in one job (deps, babl, GEGL, GIMP itself) for now, for simplicity of debugging. We'll see later to break this into CI sub-jobs.
2021-05-02 21:43:25 +08:00
tags:
- win32-ps
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/build-gimp-msys2.sh"
build: do not build Windows dependencies with ccache. The build rules were highly inspired by other projects on GNOME's Gitlab. All of them used to build with ccache. It worked fine for the main build, but completely broke GObject Introspection build on both babl and GEGL. And the worse thing is that meson was absolutely not displaying the error, just saying it failed (even in verbose mode). A lot of time wasted trying to debug. Therefore let's get rid of ccache, but only for babl and GEGL. Keep it for GIMP itself as it works fine there. Other minor changes: * Build from the build dir, rather than source. The other way around works too, but I actually find commands simpler this way. * Adding artifacts.
2021-05-04 02:01:29 +08:00
artifacts:
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
build: do not build Windows dependencies with ccache. The build rules were highly inspired by other projects on GNOME's Gitlab. All of them used to build with ccache. It worked fine for the main build, but completely broke GObject Introspection build on both babl and GEGL. And the worse thing is that meson was absolutely not displaying the error, just saying it failed (even in verbose mode). A lot of time wasted trying to debug. Therefore let's get rid of ccache, but only for babl and GEGL. Keep it for GIMP itself as it works fine there. Other minor changes: * Build from the build dir, rather than source. The other way around works too, but I actually find commands simpler this way. * Adding artifacts.
2021-05-04 02:01:29 +08:00
when: always
gitlab-ci, build: CI job to package GIMP on Windows from MSYS2 build. This new job resulted in a package which allows to run GIMP on Windows (as tested in a VM; at least it starts, I can create a new canvas and paint). Of course I think this will need to be tweaked a little bit more, as I'm sure we miss things here and there. At the very least, even though I add the Python and Luajit binaries, GIMP on Windows didn't find them. This will need to be investigated. Also it looks like opening from a remote location may not work. Not sure if this about a missing GIO module or maybe something which works differently on Windows (I was not even able to drag'n drop from the browser!). Anyway this needs to be looked at as well. Note that gdk-pixbuf-query-loaders is apparently unneeded when GIMP is built this way (unlike with our crossroad build). All this to say that this is still an early attempt to full CI build for Windows. It doesn't invalidate the crossroad build, because cross-compilation builds from Linux will always stay very important for Linux developers to be able to easily fix Windows bugs too; yet the crossroad build has 2 major issues: 1. We haven't figured out yet how to run GObject Introspection tools for cross-builds, so the crossroad builds are not full-featured (and this is quite a major feature we are missing!). 2. Also I will want to run the installer in the CI at some point and the one we use can only run on Windows itself AFAIK. We could try to run it through Wine, but still anyway the point 1. is already quite a blocker, let's do the simple thing. Note that we will likely want to move to meson for this build, because autotools is very slow on Windows. But as long as the few blocker meson bugs are not fixed, let's stick to the slow yet good build.
2021-05-07 00:40:37 +08:00
expire_in: 1 day
build: do not build Windows dependencies with ccache. The build rules were highly inspired by other projects on GNOME's Gitlab. All of them used to build with ccache. It worked fine for the main build, but completely broke GObject Introspection build on both babl and GEGL. And the worse thing is that meson was absolutely not displaying the error, just saying it failed (even in verbose mode). A lot of time wasted trying to debug. Therefore let's get rid of ccache, but only for babl and GEGL. Keep it for GIMP itself as it works fine there. Other minor changes: * Build from the build dir, rather than source. The other way around works too, but I actually find commands simpler this way. * Adding artifacts.
2021-05-04 02:01:29 +08:00
paths:
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
- _install-w64
build, gitlab-ci: generated files should be in the build dir. Also update the CI script to copy the generated language files before creating the installer so that the gimp3264.iss script finds them.
2021-06-19 02:40:04 +08:00
- _build-w64/build/windows/installer/lang/
gitlab-ci: keep the Windows native builds' config.log. This helps debugging the builds when needed.
2021-06-22 17:39:07 +08:00
- _build-w64/config.log
build: do not build Windows dependencies with ccache. The build rules were highly inspired by other projects on GNOME's Gitlab. All of them used to build with ccache. It worked fine for the main build, but completely broke GObject Introspection build on both babl and GEGL. And the worse thing is that meson was absolutely not displaying the error, just saying it failed (even in verbose mode). A lot of time wasted trying to debug. Therefore let's get rid of ccache, but only for babl and GEGL. Keep it for GIMP itself as it works fine there. Other minor changes: * Build from the build dir, rather than source. The other way around works too, but I actually find commands simpler this way. * Adding artifacts.
2021-05-04 02:01:29 +08:00
cache:
paths:
- _ccache/
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
needs: ["deps-win64-native"]
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
packaging-win64-native:
rules:
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_WIN_INSTALLER != null'
gitlab-ci: add support for flatpak and Windows installer jobs in MR… … based on set labels. If the label "5. Windows Installer" is set, the MR pipeline should trigger the Windows installer pipeline as well. If the label "5. Flatpak package" is set, it should generate the flatpak (not publish it obviously, yet it can be downloaded and installed manually). This will allow us to easily test MRs and allow people to test our code before we merge it to the main branches.
2021-05-28 19:35:40 +08:00
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
stage: packaging
variables:
MSYSTEM: "MINGW64"
CHERE_INVOKING: "yes"
tags:
- win32-ps
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/package-gimp-msys2.sh"
- cd gimp-w64
- C:\msys64\usr\bin\bash -lc "bash -x ../build/windows/gitlab-ci/split-debug-msys2.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
when: always
expire_in: 1 day
paths:
- gimp-w64
build, gitlab-ci: generated files should be in the build dir. Also update the CI script to copy the generated language files before creating the installer so that the gimp3264.iss script finds them.
2021-06-19 02:40:04 +08:00
- _build-w64/build/windows/installer/lang/
.gitlab-ci, build: avoid same DLL dependencies from previous runs. We were already avoiding re-processing a same DLL within the same run (this can happen when 2 dependencies have themselves a common dependency). But the dll_link.py script was stateless regarding previous runs so we might be checking again the same DLLs multiple times (even though we were not copying them again). Let's make the script stateful with a new parameter to give a file where all the previously processed DLL names are stored. I am hoping it would improve the efficiency of the packaging-win32-native which is suddenly extra slow (it always times out, even after raising the max job time; now we time out after 2h30! The 64-bit packaging job just takes 1h, which is too much already, but still much more reasonable).
2022-02-21 08:23:37 +08:00
- done-dll.list
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
needs: ["gimp-win64-native"]
gitlab-ci: add native Windows 32-bit build with MSYS2. Note: Vala API doesn't build well on the 32-bit build. Not sure why (the meson logs for GObject Introspection build are just as empty as ever), but it won't generate the VAPI. So I disabled the option on 32-bit.
2021-05-08 21:05:35 +08:00
## WINDOWS 32-bit CI (native MSYS2) ##
deps-win32-native:
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_MSYS2_WIN32 != null'
- if: '$GIMP_CI_WIN_INSTALLER != null'
gitlab-ci: add support for flatpak and Windows installer jobs in MR… … based on set labels. If the label "5. Windows Installer" is set, the MR pipeline should trigger the Windows installer pipeline as well. If the label "5. Flatpak package" is set, it should generate the flatpak (not publish it obviously, yet it can be downloaded and installed manually). This will allow us to easily test MRs and allow people to test our code before we merge it to the main branches.
2021-05-28 19:35:40 +08:00
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
gitlab-ci: add native Windows 32-bit build with MSYS2. Note: Vala API doesn't build well on the 32-bit build. Not sure why (the meson logs for GObject Introspection build are just as empty as ever), but it won't generate the VAPI. So I disabled the option on 32-bit.
2021-05-08 21:05:35 +08:00
stage: dependencies
variables:
MSYSTEM: "MINGW32"
CHERE_INVOKING: "yes"
tags:
- win32-ps
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/build-deps-msys2.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
when: always
expire_in: 2 hours
paths:
gitlab-ci, build: construct the Windows installer from CI. Run InnoSetup in the Windows CI to build the installer from both the 32 and 64-bit builds. Current limitations: - No installer signature yet. - Dependencies will have to be checked more thoroughly. - Apart from babl and GEGL, we may want to make custom builds of any package which has a patch in build/windows/patches/ (Windows-specific patches) and build/patches/ (all platform patches). - Plug-in interpreters (Python, Lua…) don't work. This will need to be looked at in detail. Globally this first automated installer build works fine though, as I could install it in a Windows 10 VM and GIMP ran fine! So it's a first step towards fully automated releases for Windows.
2021-05-11 03:50:49 +08:00
- _install-w32
gitlab-ci: add native Windows 32-bit build with MSYS2. Note: Vala API doesn't build well on the 32-bit build. Not sure why (the meson logs for GObject Introspection build are just as empty as ever), but it won't generate the VAPI. So I disabled the option on 32-bit.
2021-05-08 21:05:35 +08:00
needs: []
gimp-win32-native:
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_MSYS2_WIN32 != null'
- if: '$GIMP_CI_WIN_INSTALLER != null'
gitlab-ci: add support for flatpak and Windows installer jobs in MR… … based on set labels. If the label "5. Windows Installer" is set, the MR pipeline should trigger the Windows installer pipeline as well. If the label "5. Flatpak package" is set, it should generate the flatpak (not publish it obviously, yet it can be downloaded and installed manually). This will allow us to easily test MRs and allow people to test our code before we merge it to the main branches.
2021-05-28 19:35:40 +08:00
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
gitlab-ci: add native Windows 32-bit build with MSYS2. Note: Vala API doesn't build well on the 32-bit build. Not sure why (the meson logs for GObject Introspection build are just as empty as ever), but it won't generate the VAPI. So I disabled the option on 32-bit.
2021-05-08 21:05:35 +08:00
stage: gimp
variables:
MSYSTEM: "MINGW32"
CHERE_INVOKING: "yes"
tags:
- win32-ps
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/build-gimp-msys2.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
when: always
expire_in: 1 day
paths:
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
- _install-w32
gitlab-ci: keep the Windows native builds' config.log. This helps debugging the builds when needed.
2021-06-22 17:39:07 +08:00
- _build-w32/config.log
gitlab-ci: add native Windows 32-bit build with MSYS2. Note: Vala API doesn't build well on the 32-bit build. Not sure why (the meson logs for GObject Introspection build are just as empty as ever), but it won't generate the VAPI. So I disabled the option on 32-bit.
2021-05-08 21:05:35 +08:00
cache:
paths:
- _ccache/
needs: ["deps-win32-native"]
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
packaging-win32-native:
rules:
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_WIN_INSTALLER != null'
gitlab-ci: add support for flatpak and Windows installer jobs in MR… … based on set labels. If the label "5. Windows Installer" is set, the MR pipeline should trigger the Windows installer pipeline as well. If the label "5. Flatpak package" is set, it should generate the flatpak (not publish it obviously, yet it can be downloaded and installed manually). This will allow us to easily test MRs and allow people to test our code before we merge it to the main branches.
2021-05-28 19:35:40 +08:00
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
stage: packaging
variables:
MSYSTEM: "MINGW32"
CHERE_INVOKING: "yes"
tags:
- win32-ps
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/package-gimp-msys2.sh"
- cd gimp-w32
- C:\msys64\usr\bin\bash -lc "bash -x ../build/windows/gitlab-ci/split-debug-msys2.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
when: always
expire_in: 1 day
paths:
- gimp-w32
.gitlab-ci, build: avoid same DLL dependencies from previous runs. We were already avoiding re-processing a same DLL within the same run (this can happen when 2 dependencies have themselves a common dependency). But the dll_link.py script was stateless regarding previous runs so we might be checking again the same DLLs multiple times (even though we were not copying them again). Let's make the script stateful with a new parameter to give a file where all the previously processed DLL names are stored. I am hoping it would improve the efficiency of the packaging-win32-native which is suddenly extra slow (it always times out, even after raising the max job time; now we time out after 2h30! The 64-bit packaging job just takes 1h, which is too much already, but still much more reasonable).
2022-02-21 08:23:37 +08:00
- done-dll.list
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
needs: ["gimp-win32-native"]
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
## WINDOWS 64-bit CI (cross-build crossroad) ##
gitlab-ci, build: testing native Windows build. Just an initial test to get a hang of the thing, mostly inspired from GTK gitlab-ci rules adapted to our build. All in one job (deps, babl, GEGL, GIMP itself) for now, for simplicity of debugging. We'll see later to break this into CI sub-jobs.
2021-05-02 21:43:25 +08:00
gitlab-ci: job renaming.
2019-11-26 02:16:40 +08:00
deps-win64:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On commits except tags.
- if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_TAG == null'
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
# On merge requests.
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_CROSSROAD_WIN64 != null'
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
stage: dependencies
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
image: $CI_REGISTRY_IMAGE:build-win64-latest
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
variables:
XDG_CACHE_HOME: "$CI_PROJECT_DIR/.cache/"
XDG_DATA_HOME: "$CI_PROJECT_DIR/.local/share/"
cache:
paths:
- .cache/crossroad/
app: CI cache now configured in GNOME gitlab. Let's reimplement some caching of packages for Debian apt and crossroad. Hopefully it should speed up subsequent builds.
2020-05-29 01:51:50 +08:00
- apt-cache
build, gitlab-ci: add a script to cross-build GIMP with Gitlab CI. It looks like Arch does not have mingw64 cross-compilers in core package repository. It does have some package in the user repository (AUR), but I assume that such a repository cannot be deemed as safe. Anyway I still tried, but apparently these AUR packages have to be built and when I tried, I got this error: > ERROR: Running makepkg as root is not allowed as it can cause > permanent, catastrophic damage to your system. Anyway it's all a big mess. Then I tried to move the cross-CI to Debian testing, which is anyway our base compatibility system. Unfortunately I encountered like what looked like some glibc++ macro problem on some packages (most likely because the pre-built packages I use are Fedora ones which likely uses a cross-compiler differently built from the Debian one). So in the end, for simplicity, I use a Fedora image, then I am sure to get a good match between the system cross-compiler and the pre-built dependencies.
2019-09-25 20:27:09 +08:00
before_script:
gitlab-ci: "needs" jobs have to be in a prior stage.
2020-10-02 19:21:21 +08:00
- apt-get update
- apt-get install -y --no-install-recommends wine wine64
build: use msys2 packages as source for the Windows CI. This is a new feature I implemented in the crossroad cross-compilation tool. Msys2 repository has more packages and they are more up-to-date compared to Fedora and Suse cross-built packages (the 2 other available sources for pre-built Windows packages). This allows to simplify a lot the dependency preparation for the Windows CI, and speed things up.
2020-04-16 21:19:36 +08:00
- git clone --depth=${GIT_DEPTH} git://git.tuxfamily.org/gitroot/crossroad/crossroad.git
build, gitlab-ci: add a script to cross-build GIMP with Gitlab CI. It looks like Arch does not have mingw64 cross-compilers in core package repository. It does have some package in the user repository (AUR), but I assume that such a repository cannot be deemed as safe. Anyway I still tried, but apparently these AUR packages have to be built and when I tried, I got this error: > ERROR: Running makepkg as root is not allowed as it can cause > permanent, catastrophic damage to your system. Anyway it's all a big mess. Then I tried to move the cross-CI to Debian testing, which is anyway our base compatibility system. Unfortunately I encountered like what looked like some glibc++ macro problem on some packages (most likely because the pre-built packages I use are Fedora ones which likely uses a cross-compiler differently built from the Debian one). So in the end, for simplicity, I use a Fedora image, then I am sure to get a good match between the system cross-compiler and the pre-built dependencies.
2019-09-25 20:27:09 +08:00
- cd crossroad
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
- ./setup.py install --prefix=`pwd`/../.local
build, gitlab-ci: add a script to cross-build GIMP with Gitlab CI. It looks like Arch does not have mingw64 cross-compilers in core package repository. It does have some package in the user repository (AUR), but I assume that such a repository cannot be deemed as safe. Anyway I still tried, but apparently these AUR packages have to be built and when I tried, I got this error: > ERROR: Running makepkg as root is not allowed as it can cause > permanent, catastrophic damage to your system. Anyway it's all a big mess. Then I tried to move the cross-CI to Debian testing, which is anyway our base compatibility system. Unfortunately I encountered like what looked like some glibc++ macro problem on some packages (most likely because the pre-built packages I use are Fedora ones which likely uses a cross-compiler differently built from the Debian one). So in the end, for simplicity, I use a Fedora image, then I am sure to get a good match between the system cross-compiler and the pre-built dependencies.
2019-09-25 20:27:09 +08:00
- cd ..
gitlab-ci: fix Windows CI builds. Seems that msys2 packages can sometimes be compressed as `.tar.zst` instead of `.tar.xz`. I updated crossroad to handle this case. It now requires the additional pypi `zstandard` package.
2020-04-27 20:46:11 +08:00
- pip3 install zstandard
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
script:
- export PATH="`pwd`/.local/bin:$PATH"
Build libjxl in crossroad Win64 CI
2021-09-29 15:43:39 +08:00
# libjxl uses C++ features that require posix threads
- update-alternatives --set x86_64-w64-mingw32-g++ /usr/bin/x86_64-w64-mingw32-g++-posix
- update-alternatives --set x86_64-w64-mingw32-gcc /usr/bin/x86_64-w64-mingw32-gcc-posix
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
- crossroad w64 gimp --run="build/windows/gitlab-ci/build-deps-crossroad.sh"
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
artifacts:
gitlab-ci: name the distribution artifacts and small build-deps.sh fix. This should give a nice name to distribution archives so that they are not all called `artifacts.zip`. Names will better describe their contents (target OS or source and short commit hash, because for CI builds, it's important to know which commit is being tested). Also replace CI_COMMIT_REF_NAME in other artifact names by CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in branch names), only the part after the last slash is used for archive naming. Finally immediately exits from dependency build with error code (!= 0) if `crossroad install` command failed.
2020-10-04 00:04:27 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
when: always
.gitlab-ci.yml: change artifact expiry to 2 hours for dependencies and 1 day for MS Windows builds
2020-05-04 00:29:43 +08:00
expire_in: 2 hours
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
paths:
- .local/
- _deps/
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
needs: ["build-image-win64"]
build, gitlab-ci: add a script to cross-build GIMP with Gitlab CI. It looks like Arch does not have mingw64 cross-compilers in core package repository. It does have some package in the user repository (AUR), but I assume that such a repository cannot be deemed as safe. Anyway I still tried, but apparently these AUR packages have to be built and when I tried, I got this error: > ERROR: Running makepkg as root is not allowed as it can cause > permanent, catastrophic damage to your system. Anyway it's all a big mess. Then I tried to move the cross-CI to Debian testing, which is anyway our base compatibility system. Unfortunately I encountered like what looked like some glibc++ macro problem on some packages (most likely because the pre-built packages I use are Fedora ones which likely uses a cross-compiler differently built from the Debian one). So in the end, for simplicity, I use a Fedora image, then I am sure to get a good match between the system cross-compiler and the pre-built dependencies.
2019-09-25 20:27:09 +08:00
gitlab-ci: job renaming.
2019-11-26 02:16:40 +08:00
gimp-win64:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On commits except tags.
- if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_TAG == null'
gitlab-ci: make sure the normal commit jobs are also run on MR. In particular the autotools, meson Linux jobs and the Win64 crossroad job.
2021-05-28 23:27:50 +08:00
# On merge requests.
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_CROSSROAD_WIN64 != null'
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
stage: gimp
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
image: $CI_REGISTRY_IMAGE:build-win64-latest
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
dependencies:
gitlab-ci: job renaming.
2019-11-26 02:16:40 +08:00
- deps-win64
gitlab-ci: fix crossroad and dnf caching. This should hopefully speed up successive builds as most packages don't need to be re-downloaded.
2019-10-01 19:44:42 +08:00
variables:
XDG_CACHE_HOME: "$CI_PROJECT_DIR/.cache/"
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
XDG_DATA_HOME: "$CI_PROJECT_DIR/.local/share/"
gitlab-ci: fix crossroad and dnf caching. This should hopefully speed up successive builds as most packages don't need to be re-downloaded.
2019-10-01 19:44:42 +08:00
cache:
paths:
- .cache/crossroad/
app: CI cache now configured in GNOME gitlab. Let's reimplement some caching of packages for Debian apt and crossroad. Hopefully it should speed up subsequent builds.
2020-05-29 01:51:50 +08:00
- apt-cache
build, gitlab-ci: add a script to cross-build GIMP with Gitlab CI. It looks like Arch does not have mingw64 cross-compilers in core package repository. It does have some package in the user repository (AUR), but I assume that such a repository cannot be deemed as safe. Anyway I still tried, but apparently these AUR packages have to be built and when I tried, I got this error: > ERROR: Running makepkg as root is not allowed as it can cause > permanent, catastrophic damage to your system. Anyway it's all a big mess. Then I tried to move the cross-CI to Debian testing, which is anyway our base compatibility system. Unfortunately I encountered like what looked like some glibc++ macro problem on some packages (most likely because the pre-built packages I use are Fedora ones which likely uses a cross-compiler differently built from the Debian one). So in the end, for simplicity, I use a Fedora image, then I am sure to get a good match between the system cross-compiler and the pre-built dependencies.
2019-09-25 20:27:09 +08:00
script:
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
- export PATH="`pwd`/.local/bin:$PATH"
- mkdir _build && cd _build
- echo 'crossroad meson ..
crossroad gimp-win64 build: update gi-docgen feature setting
2021-12-29 19:55:09 +08:00
-Dgi-docgen=disabled && ninja && ninja install &&
gitlab-ci: move the prefix to root for simpler paths in artefacts.
2019-10-25 04:47:56 +08:00
cp -fr $CROSSROAD_PREFIX/ ../gimp-prefix/
gitlab-ci, build: add a wrapper for GIMP binary to Win32 CI result. A few commands need to be performed the first time for glib to work properly, and gdk-pixbuf loaders to be found. I add them in a wrapper script so that it's easy to ask people to test the dev builds (even though it's not necessary to run these commands each time, but who cares!).
2019-10-25 04:20:20 +08:00
' |
gitlab-ci: new build organization. Rather than having the whole Win32 cross-build into the 'gimp' stage, break the dependencies and GIMP-only builds in 2 stages. Since apparently we need to keep the same structure for the native and cross build (otherwise we don't get parallel builds; in other words, I didn't find the possibility to set separate pipelines up), I move babl and GEGL into the same 'dependencies' stage. Finally I remove the -base rules extended into actual jobs, except for `.gimp-base` (this is the only which makes sense as it is actually common to the meson and autotools build).
2019-10-02 03:36:19 +08:00
crossroad w64 gimp --run="-"
gitlab-ci: job renaming.
2019-11-26 02:16:40 +08:00
needs: ["deps-win64"]
build, gitlab-ci: add a script to cross-build GIMP with Gitlab CI. It looks like Arch does not have mingw64 cross-compilers in core package repository. It does have some package in the user repository (AUR), but I assume that such a repository cannot be deemed as safe. Anyway I still tried, but apparently these AUR packages have to be built and when I tried, I got this error: > ERROR: Running makepkg as root is not allowed as it can cause > permanent, catastrophic damage to your system. Anyway it's all a big mess. Then I tried to move the cross-CI to Debian testing, which is anyway our base compatibility system. Unfortunately I encountered like what looked like some glibc++ macro problem on some packages (most likely because the pre-built packages I use are Fedora ones which likely uses a cross-compiler differently built from the Debian one). So in the end, for simplicity, I use a Fedora image, then I am sure to get a good match between the system cross-compiler and the pre-built dependencies.
2019-09-25 20:27:09 +08:00
artifacts:
gitlab-ci: name the distribution artifacts and small build-deps.sh fix. This should give a nice name to distribution archives so that they are not all called `artifacts.zip`. Names will better describe their contents (target OS or source and short commit hash, because for CI builds, it's important to know which commit is being tested). Also replace CI_COMMIT_REF_NAME in other artifact names by CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in branch names), only the part after the last slash is used for archive naming. Finally immediately exits from dependency build with error code (!= 0) if `crossroad install` command failed.
2020-10-04 00:04:27 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
gitlab-ci: improve artifacts settings. First replace the "when: on_failure" rule by a "when: always". We indeed always want to get log artifact so that we can study a build if necessary (neither only on failure nor on success; really on all cases, since even an apparently successful build may have issues we might want to diagnose). Also expire all artifacts at 1 week (it seems the default on GNOME's Gitlab is 4 weeks; we don't need to keep these so long. Even a few days might be enough actually). As for the artifacts contents, keep the build dirs rather than the install dirs. Build dirs allow to check configuration logs and other kind of logs which are the most useful when diagnosing a failed build. Now install dirs are also interesting. Maybe we should provide them again at some point. We'll see. For now I comment them out. Still keep the install dir for dependencies though, since it seems this is how data are passed from one job to another. Note that ideally we would like to provide different artifacts depending on failure or success but apparently this is currently not possible. See: https://gitlab.com/gitlab-org/gitlab/issues/18744 Also not sure why for GIMP, the CI was only keeping the build app/tests/ directory. We should really keep the whole dir.
2019-10-02 00:36:07 +08:00
when: always
.gitlab-ci.yml: expire all dependencies in 2 hours, and all builds in 1 day
2020-05-09 19:19:18 +08:00
expire_in: 1 day
build, gitlab-ci: add a script to cross-build GIMP with Gitlab CI. It looks like Arch does not have mingw64 cross-compilers in core package repository. It does have some package in the user repository (AUR), but I assume that such a repository cannot be deemed as safe. Anyway I still tried, but apparently these AUR packages have to be built and when I tried, I got this error: > ERROR: Running makepkg as root is not allowed as it can cause > permanent, catastrophic damage to your system. Anyway it's all a big mess. Then I tried to move the cross-CI to Debian testing, which is anyway our base compatibility system. Unfortunately I encountered like what looked like some glibc++ macro problem on some packages (most likely because the pre-built packages I use are Fedora ones which likely uses a cross-compiler differently built from the Debian one). So in the end, for simplicity, I use a Fedora image, then I am sure to get a good match between the system cross-compiler and the pre-built dependencies.
2019-09-25 20:27:09 +08:00
paths:
- _build/
gitlab-ci: move the prefix to root for simpler paths in artefacts.
2019-10-25 04:47:56 +08:00
- gimp-prefix/
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
## WINDOWS 32-bit CI (cross-build crossroad) ##
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
gitlab-ci: job renaming.
2019-11-26 02:16:40 +08:00
deps-win32:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_CROSSROAD_WIN32 != null'
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
stage: dependencies
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
image: $CI_REGISTRY_IMAGE:build-win32-latest
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
variables:
XDG_CACHE_HOME: "$CI_PROJECT_DIR/.cache/"
XDG_DATA_HOME: "$CI_PROJECT_DIR/.local/share/"
cache:
paths:
- .cache/crossroad/
app: CI cache now configured in GNOME gitlab. Let's reimplement some caching of packages for Debian apt and crossroad. Hopefully it should speed up subsequent builds.
2020-05-29 01:51:50 +08:00
- apt-cache
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
before_script:
build: use msys2 packages as source for the Windows CI. This is a new feature I implemented in the crossroad cross-compilation tool. Msys2 repository has more packages and they are more up-to-date compared to Fedora and Suse cross-built packages (the 2 other available sources for pre-built Windows packages). This allows to simplify a lot the dependency preparation for the Windows CI, and speed things up.
2020-04-16 21:19:36 +08:00
- git clone --depth=${GIT_DEPTH} git://git.tuxfamily.org/gitroot/crossroad/crossroad.git
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
- cd crossroad
- ./setup.py install --prefix=`pwd`/../.local
- cd ..
gitlab-ci: fix Windows CI builds. Seems that msys2 packages can sometimes be compressed as `.tar.zst` instead of `.tar.xz`. I updated crossroad to handle this case. It now requires the additional pypi `zstandard` package.
2020-04-27 20:46:11 +08:00
- pip3 install zstandard
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
script:
- export PATH="`pwd`/.local/bin:$PATH"
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
- crossroad w32 gimp --run="build/windows/gitlab-ci/build-deps-crossroad.sh"
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
artifacts:
gitlab-ci: name the distribution artifacts and small build-deps.sh fix. This should give a nice name to distribution archives so that they are not all called `artifacts.zip`. Names will better describe their contents (target OS or source and short commit hash, because for CI builds, it's important to know which commit is being tested). Also replace CI_COMMIT_REF_NAME in other artifact names by CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in branch names), only the part after the last slash is used for archive naming. Finally immediately exits from dependency build with error code (!= 0) if `crossroad install` command failed.
2020-10-04 00:04:27 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
when: always
.gitlab-ci.yml: expire all dependencies in 2 hours, and all builds in 1 day
2020-05-09 19:19:18 +08:00
expire_in: 2 hours
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
paths:
- .local/
- _deps/
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
needs: ["build-image-win32"]
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
gitlab-ci: job renaming.
2019-11-26 02:16:40 +08:00
gimp-win32:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_CROSSROAD_WIN32 != null'
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
stage: gimp
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
image: $CI_REGISTRY_IMAGE:build-win32-latest
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
dependencies:
gitlab-ci: job renaming.
2019-11-26 02:16:40 +08:00
- deps-win32
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
variables:
XDG_CACHE_HOME: "$CI_PROJECT_DIR/.cache/"
XDG_DATA_HOME: "$CI_PROJECT_DIR/.local/share/"
cache:
paths:
- .cache/crossroad/
app: CI cache now configured in GNOME gitlab. Let's reimplement some caching of packages for Debian apt and crossroad. Hopefully it should speed up subsequent builds.
2020-05-29 01:51:50 +08:00
- apt-cache
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
script:
- export PATH="`pwd`/.local/bin:$PATH"
- mkdir _build && cd _build
- echo 'crossroad meson ..
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
-Dwmf=disabled -Dmng=disabled -Dgi_docgen=false && ninja && ninja install &&
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
cp -fr $CROSSROAD_PREFIX/ ../gimp-prefix/
' |
crossroad w32 gimp --run="-"
gitlab-ci: job renaming.
2019-11-26 02:16:40 +08:00
needs: ["deps-win32"]
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
artifacts:
gitlab-ci: name the distribution artifacts and small build-deps.sh fix. This should give a nice name to distribution archives so that they are not all called `artifacts.zip`. Names will better describe their contents (target OS or source and short commit hash, because for CI builds, it's important to know which commit is being tested). Also replace CI_COMMIT_REF_NAME in other artifact names by CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in branch names), only the part after the last slash is used for archive naming. Finally immediately exits from dependency build with error code (!= 0) if `crossroad install` command failed.
2020-10-04 00:04:27 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
when: always
.gitlab-ci.yml: change artifact expiry to 2 hours for dependencies and 1 day for MS Windows builds
2020-05-04 00:29:43 +08:00
expire_in: 1 day
gitlab-ci: add a Windows 32-bit CI. Some issues may happen only for 32-bit builds. So it may be worth make a Windows 32-bit build too. Issue #2794 triggered this reasonning, though in this issue's case, simply the build would not have discovered the bug since it was only a build warning + run-time bug. Still long-term if we manage to get a no-warning build, it could become relevant to discover more errors at build time. So preparing the ground work here.
2019-11-25 02:41:06 +08:00
paths:
- _build/
- gimp-prefix/
gitlab-ci: add an analysis stage with cppcheck code analysis stage. As contributed by Rafał @qarmin in a Gitlab comment. See #5002.
2020-04-29 00:39:32 +08:00
ci: Enable nightly flatpak builds To get a nightly flatpak, GNOME project offers a CI template[0] that can be extended instead of having to define everything from scratch. At the core is the "flatpak" job that tries to build the flatpak. If the build finishes succesfully, the result should be available as a CI artifact as a flatpak bundle. The app id is the same as on Flathub. Another part is the "flatpak-nightly" job that publishes the flatpak if the build succeeded. Without this job, the bundle stays only temporarily. This job can and should only be run on the "master" branch. This jobs is started only when the "flatpak" job finishes successfully. Both jobs can be triggered only thorugh schedules[1]. To finish the flatpak nightlies setup, a schedule needs to be set. [0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak [1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
2020-09-07 23:49:37 +08:00
## Linux Flatpak nightly CI ##
## To learn more about the CI, go to https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak
flatpak:
gitlab-ci: do not run `meson test` anymore inside the flatpak job. Somehow the test part of the flatpak job stopped working. The last instance which worked was 3 weeks ago, but after a lot of debugging I realized that it is not because of any code change on our side. The exact same commit which worked 3 weeks ago won't anymore! The standalone bundle is actually built and works fine when tested independently. What fails is the `meson test` inside the flatpak environment. Somehow when GIMP is rebuilt inside the test flatpak environment, it doesn't build the plug-ins yet one of our tests (save-and-export) requires plug-ins to open some file formats. Note that I double-checked, the plug-ins were well built and loading any format works fine in the standalone flatpak, just not in this specific step. I am completely unsure what broke, yet it is apparently outside GIMP code. So for now, I just copy-paste the whole flatpak job which we were including from another repository and remove the `meson test` part.
2021-07-26 03:58:04 +08:00
image: 'registry.gitlab.gnome.org/gnome/gnome-runtime-images/gnome:master'
ci: Enable nightly flatpak builds To get a nightly flatpak, GNOME project offers a CI template[0] that can be extended instead of having to define everything from scratch. At the core is the "flatpak" job that tries to build the flatpak. If the build finishes succesfully, the result should be available as a CI artifact as a flatpak bundle. The app id is the same as on Flathub. Another part is the "flatpak-nightly" job that publishes the flatpak if the build succeeded. Without this job, the bundle stays only temporarily. This job can and should only be run on the "master" branch. This jobs is started only when the "flatpak" job finishes successfully. Both jobs can be triggered only thorugh schedules[1]. To finish the flatpak nightlies setup, a schedule needs to be set. [0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak [1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
2020-09-07 23:49:37 +08:00
stage: gimp
gitlab-ci: do not run `meson test` anymore inside the flatpak job. Somehow the test part of the flatpak job stopped working. The last instance which worked was 3 weeks ago, but after a lot of debugging I realized that it is not because of any code change on our side. The exact same commit which worked 3 weeks ago won't anymore! The standalone bundle is actually built and works fine when tested independently. What fails is the `meson test` inside the flatpak environment. Somehow when GIMP is rebuilt inside the test flatpak environment, it doesn't build the plug-ins yet one of our tests (save-and-export) requires plug-ins to open some file formats. Note that I double-checked, the plug-ins were well built and loading any format works fine in the standalone flatpak, just not in this specific step. I am completely unsure what broke, yet it is apparently outside GIMP code. So for now, I just copy-paste the whole flatpak job which we were including from another repository and remove the `meson test` part.
2021-07-26 03:58:04 +08:00
tags:
- flatpak
ci: Enable nightly flatpak builds To get a nightly flatpak, GNOME project offers a CI template[0] that can be extended instead of having to define everything from scratch. At the core is the "flatpak" job that tries to build the flatpak. If the build finishes succesfully, the result should be available as a CI artifact as a flatpak bundle. The app id is the same as on Flathub. Another part is the "flatpak-nightly" job that publishes the flatpak if the build succeeded. Without this job, the bundle stays only temporarily. This job can and should only be run on the "master" branch. This jobs is started only when the "flatpak" job finishes successfully. Both jobs can be triggered only thorugh schedules[1]. To finish the flatpak nightlies setup, a schedule needs to be set. [0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak [1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
2020-09-07 23:49:37 +08:00
needs: []
gitlab-ci: create a GIMP_CI_FLATPAK Gitlab variable to trigger the… … flatpak build and publishing. Same as we are doing for other build pipelines. This allows finer manual builds (not just "on schedules").
2021-05-27 01:35:19 +08:00
rules:
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_FLATPAK != null'
gitlab-ci: add support for flatpak and Windows installer jobs in MR… … based on set labels. If the label "5. Windows Installer" is set, the MR pipeline should trigger the Windows installer pipeline as well. If the label "5. Flatpak package" is set, it should generate the flatpak (not publish it obviously, yet it can be downloaded and installed manually). This will allow us to easily test MRs and allow people to test our code before we merge it to the main branches.
2021-05-28 19:35:40 +08:00
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Flatpak package.*/'
ci: Enable nightly flatpak builds To get a nightly flatpak, GNOME project offers a CI template[0] that can be extended instead of having to define everything from scratch. At the core is the "flatpak" job that tries to build the flatpak. If the build finishes succesfully, the result should be available as a CI artifact as a flatpak bundle. The app id is the same as on Flathub. Another part is the "flatpak-nightly" job that publishes the flatpak if the build succeeded. Without this job, the bundle stays only temporarily. This job can and should only be run on the "master" branch. This jobs is started only when the "flatpak" job finishes successfully. Both jobs can be triggered only thorugh schedules[1]. To finish the flatpak nightlies setup, a schedule needs to be set. [0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak [1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
2020-09-07 23:49:37 +08:00
variables:
GIT_SUBMODULE_STRATEGY: normal
# Replace with your manifest path
MANIFEST_PATH: "build/flatpak/org.gimp.GIMP-nightly.json"
RUNTIME_REPO: "https://nightly.gnome.org/gnome-nightly.flatpakrepo"
# Replace with your application name, as written in the manifest
FLATPAK_MODULE: "gimp"
APP_ID: "org.gimp.GIMP"
BUNDLE: "gimp-git.flatpak"
gitlab-ci: do not run `meson test` anymore inside the flatpak job. Somehow the test part of the flatpak job stopped working. The last instance which worked was 3 weeks ago, but after a lot of debugging I realized that it is not because of any code change on our side. The exact same commit which worked 3 weeks ago won't anymore! The standalone bundle is actually built and works fine when tested independently. What fails is the `meson test` inside the flatpak environment. Somehow when GIMP is rebuilt inside the test flatpak environment, it doesn't build the plug-ins yet one of our tests (save-and-export) requires plug-ins to open some file formats. Note that I double-checked, the plug-ins were well built and loading any format works fine in the standalone flatpak, just not in this specific step. I am completely unsure what broke, yet it is apparently outside GIMP code. So for now, I just copy-paste the whole flatpak job which we were including from another repository and remove the `meson test` part.
2021-07-26 03:58:04 +08:00
script:
# Report the installed versions of the runtime
- flatpak info org.gnome.Platform
- flatpak info org.gnome.Sdk
# Print the date, since appstream depends on local timezone
- date && date -u
- rewrite-flatpak-manifest ${MANIFEST_PATH} ${FLATPAK_MODULE} ${CONFIG_OPTS}
gitlab-ci: store flatpak-build output into a log file. Without this, the flatpak build is just too long and Gitlab CI just stops logging it. So we end up with a log saying the quite useless (at the end): > Job's log exceeded limit of 16777216 bytes. > Job execution will continue but no more output will be collected. We don't even reach babl/GEGL/GIMP builds, which are the most important. With this little trick, I am redirecting output to a log file and simply including said log into the artifacts, hence allowing to debug the full build.
2021-05-27 02:28:47 +08:00
# Our script is too long for Gitlab and ends up with:
# > Job's log exceeded limit of 16777216 bytes.
# > Job execution will continue but no more output will be collected.
# To make debugging actually possible, let's save logs as a file.
gitlab-ci: flatpak artifacts must always be uploaded. artifacts:when is set to on_success by default. Yet we clearly need the build logs in failure case too in order to debug. See: https://docs.gitlab.com/ee/ci/yaml/#artifactswhen
2021-09-05 20:26:44 +08:00
- flatpak-builder --user --disable-rofiles-fuse flatpak_app --repo=repo ${BRANCH:+--default-branch=$BRANCH} ${MANIFEST_PATH}
> flatpak-builder.log 2>&1
gitlab-ci: do not run `meson test` anymore inside the flatpak job. Somehow the test part of the flatpak job stopped working. The last instance which worked was 3 weeks ago, but after a lot of debugging I realized that it is not because of any code change on our side. The exact same commit which worked 3 weeks ago won't anymore! The standalone bundle is actually built and works fine when tested independently. What fails is the `meson test` inside the flatpak environment. Somehow when GIMP is rebuilt inside the test flatpak environment, it doesn't build the plug-ins yet one of our tests (save-and-export) requires plug-ins to open some file formats. Note that I double-checked, the plug-ins were well built and loading any format works fine in the standalone flatpak, just not in this specific step. I am completely unsure what broke, yet it is apparently outside GIMP code. So for now, I just copy-paste the whole flatpak job which we were including from another repository and remove the `meson test` part.
2021-07-26 03:58:04 +08:00
# Generate a Flatpak bundle
- flatpak build-bundle repo ${BUNDLE} --runtime-repo=${RUNTIME_REPO} ${APP_ID} ${BRANCH}
- tar cf repo.tar repo/
# XXX This job is mostly the same as .flatpak job of
# flatpak_ci_initiative.yml so far, except that I removed the
# automatic tests inside the Flatpak env at the end. The reason is
# that this part suddenly stopped working (even though the flatpak
# itself is functional) because the rebuild somehow was not
# rebuilding plug-ins. Yet one of the test (save-and-export)
# requires plug-ins to be built.
gitlab-ci: store flatpak-build output into a log file. Without this, the flatpak build is just too long and Gitlab CI just stops logging it. So we end up with a log saying the quite useless (at the end): > Job's log exceeded limit of 16777216 bytes. > Job execution will continue but no more output will be collected. We don't even reach babl/GEGL/GIMP builds, which are the most important. With this little trick, I am redirecting output to a log file and simply including said log into the artifacts, hence allowing to debug the full build.
2021-05-27 02:28:47 +08:00
artifacts:
gitlab-ci: flatpak artifacts must always be uploaded. artifacts:when is set to on_success by default. Yet we clearly need the build logs in failure case too in order to debug. See: https://docs.gitlab.com/ee/ci/yaml/#artifactswhen
2021-09-05 20:26:44 +08:00
when: always
gitlab-ci: store flatpak-build output into a log file. Without this, the flatpak build is just too long and Gitlab CI just stops logging it. So we end up with a log saying the quite useless (at the end): > Job's log exceeded limit of 16777216 bytes. > Job execution will continue but no more output will be collected. We don't even reach babl/GEGL/GIMP builds, which are the most important. With this little trick, I am redirecting output to a log file and simply including said log into the artifacts, hence allowing to debug the full build.
2021-05-27 02:28:47 +08:00
paths:
- flatpak-builder.log
# These are the same as flatpak_ci_initiative.yml as according to
# docs, key values are not merged but replaced.
- "${BUNDLE}"
- 'repo.tar'
- '.flatpak-builder/build/${FLATPAK_MODULE}/_flatpak_build/meson-logs/meson-log.txt'
- '.flatpak-builder/build/${FLATPAK_MODULE}/_flatpak_build/meson-logs/testlog.txt'
gitlab-ci: do not run `meson test` anymore inside the flatpak job. Somehow the test part of the flatpak job stopped working. The last instance which worked was 3 weeks ago, but after a lot of debugging I realized that it is not because of any code change on our side. The exact same commit which worked 3 weeks ago won't anymore! The standalone bundle is actually built and works fine when tested independently. What fails is the `meson test` inside the flatpak environment. Somehow when GIMP is rebuilt inside the test flatpak environment, it doesn't build the plug-ins yet one of our tests (save-and-export) requires plug-ins to open some file formats. Note that I double-checked, the plug-ins were well built and loading any format works fine in the standalone flatpak, just not in this specific step. I am completely unsure what broke, yet it is apparently outside GIMP code. So for now, I just copy-paste the whole flatpak job which we were including from another repository and remove the `meson test` part.
2021-07-26 03:58:04 +08:00
expire_in: 1 week
cache:
- key: "$CI_JOB_NAME"
paths:
- '.flatpak-builder/downloads'
- '.flatpak-builder/git'
- key: "$CI_JOB_NAME"
paths:
- '.flatpak-builder/cache'
- '.flatpak-builder/ccache'
ci: Enable nightly flatpak builds To get a nightly flatpak, GNOME project offers a CI template[0] that can be extended instead of having to define everything from scratch. At the core is the "flatpak" job that tries to build the flatpak. If the build finishes succesfully, the result should be available as a CI artifact as a flatpak bundle. The app id is the same as on Flathub. Another part is the "flatpak-nightly" job that publishes the flatpak if the build succeeded. Without this job, the bundle stays only temporarily. This job can and should only be run on the "master" branch. This jobs is started only when the "flatpak" job finishes successfully. Both jobs can be triggered only thorugh schedules[1]. To finish the flatpak nightlies setup, a schedule needs to be set. [0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak [1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
2020-09-07 23:49:37 +08:00
gitlab-ci: add an analysis stage with cppcheck code analysis stage. As contributed by Rafał @qarmin in a Gitlab comment. See #5002.
2020-04-29 00:39:32 +08:00
cppcheck:
gitlab-ci: gimp-distcheck-debian and gimp-autotools-debian redundant. We had an autotools build stopping at `make check` and a separate one for `make distcheck`. This just seems very redundant hence a waste of resources. So let's drop the job gimp-autotools-debian then add a `make check` step to gimp-distcheck-debian. Also as a side change, I move the cppcheck to being a scheduled job. It's not such resource intensive job, nor did it take much time, yet it's not like we use this information constantly. Moreover it never fails anyway (so it's not like it gives much information on a per-commit basis, unless we explicitly look into the resulting files) and with the ability to run custom jobs whenever we want, this is far enough if sometimes we need to generate the cppcheck analysis more frequently. The rest of the time, having 2 jobs of this a week (our current schedule) is far enough.
2021-05-15 01:56:55 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_CPPCHECK != null'
gitlab-ci: add an analysis stage with cppcheck code analysis stage. As contributed by Rafał @qarmin in a Gitlab comment. See #5002.
2020-04-29 00:39:32 +08:00
stage: analysis
before_script:
- apt-get update
- apt-get install -y cppcheck
script:
gitlab-ci: ignore a bunch of directories. Problem with the CI is that the source is straight in our base directory and therefore installed dependency files as well as cache or built files are in subfolders. Let's try to ignore as much as I can see. This should avoid a bunch of warning and errors during report generation.
2020-04-29 20:05:31 +08:00
- cppcheck -q -j8 --enable=all --force --output-file=cppcheck.xml --xml --xml-version=2
-i _build -i _deps -i gimp-prefix -i .local -i .cache .
gitlab-ci: add an analysis stage with cppcheck code analysis stage. As contributed by Rafał @qarmin in a Gitlab comment. See #5002.
2020-04-29 00:39:32 +08:00
- mkdir report
- cppcheck-htmlreport --source-dir=. --title=gimp --file=cppcheck.xml --report-dir=report
artifacts:
gitlab-ci: name the distribution artifacts and small build-deps.sh fix. This should give a nice name to distribution archives so that they are not all called `artifacts.zip`. Names will better describe their contents (target OS or source and short commit hash, because for CI builds, it's important to know which commit is being tested). Also replace CI_COMMIT_REF_NAME in other artifact names by CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in branch names), only the part after the last slash is used for archive naming. Finally immediately exits from dependency build with error code (!= 0) if `crossroad install` command failed.
2020-10-04 00:04:27 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
gitlab-ci: add an analysis stage with cppcheck code analysis stage. As contributed by Rafał @qarmin in a Gitlab comment. See #5002.
2020-04-29 00:39:32 +08:00
expire_in: 1 week
when: always
paths:
- report
gitlab-ci: cppcheck does not need to wait for previous stages to occur.
2020-05-05 22:21:43 +08:00
needs: []
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
.gitlab-ci.yml: add clang-format rules and pipeline Fixes #950 `.gitlab/search-common-ancestor.sh`'s original authors are Philip Withnall and Frederic Martinsons. (Jehan/reviewer's note: script further improved by Asalle)
2022-01-20 04:44:45 +08:00
clang-format:
only:
- merge_requests
stage: analysis
before_script:
- apt-get update
- apt-get install -y clang-format git
allow_failure: true
script:
- .gitlab/run_style_check_diff.sh
artifacts:
paths: ['fetch_upstream.log', 'fetch_origin.log']
when: on_failure
expire_in: 1 week
needs: []
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
## Ready-to-distribute ##
gitlab-ci, build: construct the Windows installer from CI. Run InnoSetup in the Windows CI to build the installer from both the 32 and 64-bit builds. Current limitations: - No installer signature yet. - Dependencies will have to be checked more thoroughly. - Apart from babl and GEGL, we may want to make custom builds of any package which has a patch in build/windows/patches/ (Windows-specific patches) and build/patches/ (all platform patches). - Plug-in interpreters (Python, Lua…) don't work. This will need to be looked at in detail. Globally this first automated installer build works fine though, as I could install it in a Windows 10 VM and GIMP ran fine! So it's a first step towards fully automated releases for Windows.
2021-05-11 03:50:49 +08:00
win-installer-nightly:
gitlab-ci, build: CI job to package GIMP on Windows from MSYS2 build. This new job resulted in a package which allows to run GIMP on Windows (as tested in a VM; at least it starts, I can create a new canvas and paint). Of course I think this will need to be tweaked a little bit more, as I'm sure we miss things here and there. At the very least, even though I add the Python and Luajit binaries, GIMP on Windows didn't find them. This will need to be investigated. Also it looks like opening from a remote location may not work. Not sure if this about a missing GIO module or maybe something which works differently on Windows (I was not even able to drag'n drop from the browser!). Anyway this needs to be looked at as well. Note that gdk-pixbuf-query-loaders is apparently unneeded when GIMP is built this way (unlike with our crossroad build). All this to say that this is still an early attempt to full CI build for Windows. It doesn't invalidate the crossroad build, because cross-compilation builds from Linux will always stay very important for Linux developers to be able to easily fix Windows bugs too; yet the crossroad build has 2 major issues: 1. We haven't figured out yet how to run GObject Introspection tools for cross-builds, so the crossroad builds are not full-featured (and this is quite a major feature we are missing!). 2. Also I will want to run the installer in the CI at some point and the one we use can only run on Windows itself AFAIK. We could try to run it through Wine, but still anyway the point 1. is already quite a blocker, let's do the simple thing. Note that we will likely want to move to meson for this build, because autotools is very slow on Windows. But as long as the few blocker meson bugs are not fixed, let's stick to the slow yet good build.
2021-05-07 00:40:37 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_WIN_INSTALLER != null'
gitlab-ci: add support for flatpak and Windows installer jobs in MR… … based on set labels. If the label "5. Windows Installer" is set, the MR pipeline should trigger the Windows installer pipeline as well. If the label "5. Flatpak package" is set, it should generate the flatpak (not publish it obviously, yet it can be downloaded and installed manually). This will allow us to easily test MRs and allow people to test our code before we merge it to the main branches.
2021-05-28 19:35:40 +08:00
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
gitlab-ci, build: CI job to package GIMP on Windows from MSYS2 build. This new job resulted in a package which allows to run GIMP on Windows (as tested in a VM; at least it starts, I can create a new canvas and paint). Of course I think this will need to be tweaked a little bit more, as I'm sure we miss things here and there. At the very least, even though I add the Python and Luajit binaries, GIMP on Windows didn't find them. This will need to be investigated. Also it looks like opening from a remote location may not work. Not sure if this about a missing GIO module or maybe something which works differently on Windows (I was not even able to drag'n drop from the browser!). Anyway this needs to be looked at as well. Note that gdk-pixbuf-query-loaders is apparently unneeded when GIMP is built this way (unlike with our crossroad build). All this to say that this is still an early attempt to full CI build for Windows. It doesn't invalidate the crossroad build, because cross-compilation builds from Linux will always stay very important for Linux developers to be able to easily fix Windows bugs too; yet the crossroad build has 2 major issues: 1. We haven't figured out yet how to run GObject Introspection tools for cross-builds, so the crossroad builds are not full-featured (and this is quite a major feature we are missing!). 2. Also I will want to run the installer in the CI at some point and the one we use can only run on Windows itself AFAIK. We could try to run it through Wine, but still anyway the point 1. is already quite a blocker, let's do the simple thing. Note that we will likely want to move to meson for this build, because autotools is very slow on Windows. But as long as the few blocker meson bugs are not fixed, let's stick to the slow yet good build.
2021-05-07 00:40:37 +08:00
variables:
CHERE_INVOKING: "yes"
tags:
- win32-ps
stage: distribution
dependencies:
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
- packaging-win64-native
- packaging-win32-native
Add a distribution job with Win 32-bit!
2021-05-09 22:03:53 +08:00
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}"
when: always
gitlab-ci: expire the Windows installer artifact after a week. Currently we run the job on a weekly schedule. If we keep a retention period of 2 days, it means that people will not have access to a nightly Windows installer 5 days out of 7, which is not useful. Gitlab has a retention policy not to delete artifacts for last jobs, but it apparently actually bases this check on being the last pipeline, not being actually the last job of a given name. Since we have pipelines running all the time, this retention policy just won't apply to our installer job which will get deleted. Cf. https://gitlab.com/gitlab-org/gitlab/-/issues/332142
2021-05-28 19:06:50 +08:00
expire_in: 1 week
Add a distribution job with Win 32-bit!
2021-05-09 22:03:53 +08:00
paths:
gitlab-ci, build: construct the Windows installer from CI. Run InnoSetup in the Windows CI to build the installer from both the 32 and 64-bit builds. Current limitations: - No installer signature yet. - Dependencies will have to be checked more thoroughly. - Apart from babl and GEGL, we may want to make custom builds of any package which has a patch in build/windows/patches/ (Windows-specific patches) and build/patches/ (all platform patches). - Plug-in interpreters (Python, Lua…) don't work. This will need to be looked at in detail. Globally this first automated installer build works fine though, as I could install it in a Windows 10 VM and GIMP ran fine! So it's a first step towards fully automated releases for Windows.
2021-05-11 03:50:49 +08:00
- build/windows/installer/_Output
gitlab-ci: redirect installer logs to a file. The logs are just too long for gitlab and ends with: > Job's log exceeded limit of 4194304 bytes. This doesn't prevent the job from actually finish successfully. Yet the day when we will have a build issue, we won't have a way to debug if it happens close to the end of the installer creation. So let's redirect both stderr and stdout to a log file and include it in the artifacts.
2021-05-22 22:55:04 +08:00
- installer.log
Add a distribution job with Win 32-bit!
2021-05-09 22:03:53 +08:00
script:
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci: redirect installer logs to a file. The logs are just too long for gitlab and ends with: > Job's log exceeded limit of 4194304 bytes. This doesn't prevent the job from actually finish successfully. Yet the day when we will have a build issue, we won't have a way to debug if it happens close to the end of the installer creation. So let's redirect both stderr and stdout to a log file and include it in the artifacts.
2021-05-22 22:55:04 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/installer-gimp-msys2.sh > installer.log 2>&1"
gitlab-ci: add a new "packaging" stage. Unlike what I said in my previous commit, it still just takes too long to build the installer, whether I move some of the substeps around or whether I increase the max duration. So rather than increasing max duration a lot more, let's just add an intermediate stage.
2021-05-22 01:34:00 +08:00
needs: ["packaging-win32-native", "packaging-win64-native"]
Add a distribution job with Win 32-bit!
2021-05-09 22:03:53 +08:00
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
sources:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
rules:
# On commits.
- if: '$CI_PIPELINE_SOURCE == "push"'
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_SOURCES != null'
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
stage: distribution
dependencies:
- gimp-distcheck-debian
artifacts:
gitlab-ci: name the distribution artifacts and small build-deps.sh fix. This should give a nice name to distribution archives so that they are not all called `artifacts.zip`. Names will better describe their contents (target OS or source and short commit hash, because for CI builds, it's important to know which commit is being tested). Also replace CI_COMMIT_REF_NAME in other artifact names by CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in branch names), only the part after the last slash is used for archive naming. Finally immediately exits from dependency build with error code (!= 0) if `crossroad install` command failed.
2020-10-04 00:04:27 +08:00
name: "GIMP-sources-${CI_COMMIT_SHORT_SHA}"
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
when: always
gitlab-ci: expire distribution stage artifacts after 2 days
2020-12-01 06:31:30 +08:00
expire_in: 2 days
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
paths:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
- gimp-*.tar.bz2
- gimp-*.tar.bz2.SHA256SUMS
- gimp-*.tar.bz2.SHA512SUMS
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
script:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
- mv _build/gimp-*.tar.bz2 .
- FILENAME=`ls gimp-*.tar.bz2` &&
sha256sum gimp-*.tar.bz2 > ${FILENAME}.SHA256SUMS &&
sha512sum gimp-*.tar.bz2 > ${FILENAME}.SHA512SUMS
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
needs: ["gimp-distcheck-debian"]
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
win64-nightly:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# On commits except tags.
- if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_TAG == null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_CROSSROAD_WIN64 != null'
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
stage: distribution
dependencies:
- gimp-win64
variables:
GIMP_PREFIX: "gimp-prefix"
GIMP_DISTRIB: "gimp-w64"
artifacts:
gitlab-ci: name the distribution artifacts and small build-deps.sh fix. This should give a nice name to distribution archives so that they are not all called `artifacts.zip`. Names will better describe their contents (target OS or source and short commit hash, because for CI builds, it's important to know which commit is being tested). Also replace CI_COMMIT_REF_NAME in other artifact names by CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in branch names), only the part after the last slash is used for archive naming. Finally immediately exits from dependency build with error code (!= 0) if `crossroad install` command failed.
2020-10-04 00:04:27 +08:00
name: "GIMP-Win64-CI-${CI_COMMIT_SHORT_SHA}"
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
when: always
gitlab-ci: expire distribution stage artifacts after 2 days
2020-12-01 06:31:30 +08:00
expire_in: 2 days
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
paths:
- gimp-w64
script:
- apt-get update
build: (Windows) glib-compile-schemas and gdk-pixbuf-query-loaders in… … the CI. There are 2 finale steps before finale binary distribution on Windows. We must compile the GSettings XML schema files and register GdkPixbuf loaders (for file format support in the GUI). I used to provide a wrapper to be run inside Windows before first GIMP run. Never did I realize that I can compile the distributed GSettings schemas with the native `glib-compile-schemas` (works fine in my tests). As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do require the target `gdk-pixbuf-query-loaders` which is unfortunately a Windows executable. Yet it seems to work fine with Wine, so let's be done with it in the CI instead of requiring manual steps from testers of the CI builds. Then a few `sed` calls are enough to make the path in the produced text file relative instead of absolute (which works fine, again in my tests at least). This means that I don't have to distribute the 2 binaries and the DLLs they depend on anymore. Moreover let's remove the wrapper (but still generate one which just calls GIMP so that we call it from the tree root, where it's much less messy). Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner. After following all instructions, I encountered weird errors. So instead, I just make the win32-nightly job depend on win64-nightly and copy `loaders.cache` from one to another, as it is a platform-independent text file (as long as we provide the same GdkPixbuf loaders on both of course, which we do).
2020-10-02 18:46:32 +08:00
- apt-get install -y --no-install-recommends
python3 binutils-mingw-w64-x86-64 file
libglib2.0-bin
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
# Package ressources.
- mkdir -p ${GIMP_DISTRIB}
- cp -fr ${GIMP_PREFIX}/etc ${GIMP_DISTRIB}
- cp -fr ${GIMP_PREFIX}/include ${GIMP_DISTRIB}
- cp -fr ${GIMP_PREFIX}/ssl ${GIMP_DISTRIB}
- cp -fr ${GIMP_PREFIX}/share ${GIMP_DISTRIB}
# Package executables.
- mkdir ${GIMP_DISTRIB}/bin
- cp -fr ${GIMP_PREFIX}/bin/gimp*.exe ${GIMP_DISTRIB}/bin/
- mkdir ${GIMP_DISTRIB}/libexec
- cp -fr ${GIMP_PREFIX}/libexec/gimp*.exe ${GIMP_DISTRIB}/libexec/
build: (Windows) glib-compile-schemas and gdk-pixbuf-query-loaders in… … the CI. There are 2 finale steps before finale binary distribution on Windows. We must compile the GSettings XML schema files and register GdkPixbuf loaders (for file format support in the GUI). I used to provide a wrapper to be run inside Windows before first GIMP run. Never did I realize that I can compile the distributed GSettings schemas with the native `glib-compile-schemas` (works fine in my tests). As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do require the target `gdk-pixbuf-query-loaders` which is unfortunately a Windows executable. Yet it seems to work fine with Wine, so let's be done with it in the CI instead of requiring manual steps from testers of the CI builds. Then a few `sed` calls are enough to make the path in the produced text file relative instead of absolute (which works fine, again in my tests at least). This means that I don't have to distribute the 2 binaries and the DLLs they depend on anymore. Moreover let's remove the wrapper (but still generate one which just calls GIMP so that we call it from the tree root, where it's much less messy). Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner. After following all instructions, I encountered weird errors. So instead, I just make the win32-nightly job depend on win64-nightly and copy `loaders.cache` from one to another, as it is a platform-independent text file (as long as we provide the same GdkPixbuf loaders on both of course, which we do).
2020-10-02 18:46:32 +08:00
# Add a wrapper at tree root, less messy than having to look for the
# binary inside bin/, in the middle of all the DLLs.
- echo "bin\gimp-2.99.exe" > ${GIMP_DISTRIB}/gimp.cmd
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
# Package library data and modules.
- mkdir ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/gimp ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/gio ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/gdk-pixbuf-2.0 ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/gegl-0.4 ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/babl-0.1 ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/girepository-1.0 ${GIMP_DISTRIB}/lib/
build: (Windows) glib-compile-schemas and gdk-pixbuf-query-loaders in… … the CI. There are 2 finale steps before finale binary distribution on Windows. We must compile the GSettings XML schema files and register GdkPixbuf loaders (for file format support in the GUI). I used to provide a wrapper to be run inside Windows before first GIMP run. Never did I realize that I can compile the distributed GSettings schemas with the native `glib-compile-schemas` (works fine in my tests). As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do require the target `gdk-pixbuf-query-loaders` which is unfortunately a Windows executable. Yet it seems to work fine with Wine, so let's be done with it in the CI instead of requiring manual steps from testers of the CI builds. Then a few `sed` calls are enough to make the path in the produced text file relative instead of absolute (which works fine, again in my tests at least). This means that I don't have to distribute the 2 binaries and the DLLs they depend on anymore. Moreover let's remove the wrapper (but still generate one which just calls GIMP so that we call it from the tree root, where it's much less messy). Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner. After following all instructions, I encountered weird errors. So instead, I just make the win32-nightly job depend on win64-nightly and copy `loaders.cache` from one to another, as it is a platform-independent text file (as long as we provide the same GdkPixbuf loaders on both of course, which we do).
2020-10-02 18:46:32 +08:00
# Generate share/glib-2.0/schemas/gschemas.compiled
- glib-compile-schemas --targetdir=${GIMP_DISTRIB}/share/glib-2.0/schemas ${GIMP_DISTRIB}/share/glib-2.0/schemas
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
# Package needed DLLs only
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
- python3 build/windows/gitlab-ci/dll_link.py ${GIMP_DISTRIB}/bin/gimp-2.99.exe ${GIMP_PREFIX}/ ${GIMP_DISTRIB}
- python3 build/windows/gitlab-ci/dll_link.py ${GIMP_DISTRIB}/bin/gimp-console-2.99.exe ${GIMP_PREFIX}/ ${GIMP_DISTRIB}
- python3 build/windows/gitlab-ci/dll_link.py ${GIMP_DISTRIB}/bin/gimp-test-clipboard-2.99.exe ${GIMP_PREFIX}/ ${GIMP_DISTRIB}
- python3 build/windows/gitlab-ci/dll_link.py ${GIMP_DISTRIB}/bin/gimptool-2.99.exe ${GIMP_PREFIX}/ ${GIMP_DISTRIB}
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
- for dll in ${GIMP_DISTRIB}/lib/babl-0.1/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gegl-0.4/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gio/modules/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gdk-pixbuf-2.0/2.10.0/loaders/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gimp/2.99/modules/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gimp/2.99/plug-ins/*/*.exe; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
needs: ["gimp-win64"]
win32-nightly:
gitlab-ci: improve the CI for releases. - Only publish the bz2 tarball because that's what we currently provide on download.gimp.org (let's see in the future for the xz tarball). - Generate also a sha512 checksum. It's better to do it on the CI rather than on the download server, otherwise it wouldn't protect against transfer errors (from gitlab to download server). - Rename the checksum files to ${filename}.SHA256SUMS (512 respectively) for easy download without name clash with the global files listing all the previous releases. - Disable all meson jobs for tagged releases. They are currently not reliable and may fail randomly (see issue #6257), even though without code problems (this is also one of the reasons why autotools is still our official build system and meson is still deemed experimental). It's ok for regular builds, but not for tagged builds, which we need as reliable as possible. The really important job is the distcheck one for tags.
2021-04-26 23:45:11 +08:00
rules:
gitlab-ci: reorganize pipeline rules. The goal is to make it easier to understand which pipeline is run when, for future maintenance, and also to make it easy to trigger a specific pipeline through Gitlab pipeline interface.
2021-05-17 20:34:29 +08:00
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_CROSSROAD_WIN32 != null'
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
stage: distribution
dependencies:
- gimp-win32
gitlab-ci: "needs" jobs have to be in a prior stage.
2020-10-02 19:21:21 +08:00
- deps-win64
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
variables:
GIMP_PREFIX: "gimp-prefix"
GIMP_DISTRIB: "gimp-w32"
gitlab-ci: "needs" jobs have to be in a prior stage.
2020-10-02 19:21:21 +08:00
XDG_DATA_HOME: "$CI_PROJECT_DIR/.local/share/"
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
artifacts:
gitlab-ci: name the distribution artifacts and small build-deps.sh fix. This should give a nice name to distribution archives so that they are not all called `artifacts.zip`. Names will better describe their contents (target OS or source and short commit hash, because for CI builds, it's important to know which commit is being tested). Also replace CI_COMMIT_REF_NAME in other artifact names by CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in branch names), only the part after the last slash is used for archive naming. Finally immediately exits from dependency build with error code (!= 0) if `crossroad install` command failed.
2020-10-04 00:04:27 +08:00
name: "GIMP-Win32-${CI_COMMIT_SHORT_SHA}"
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
when: always
gitlab-ci: expire distribution stage artifacts after 2 days
2020-12-01 06:31:30 +08:00
expire_in: 2 days
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
paths:
- gimp-w32
script:
- apt-get update
build: (Windows) glib-compile-schemas and gdk-pixbuf-query-loaders in… … the CI. There are 2 finale steps before finale binary distribution on Windows. We must compile the GSettings XML schema files and register GdkPixbuf loaders (for file format support in the GUI). I used to provide a wrapper to be run inside Windows before first GIMP run. Never did I realize that I can compile the distributed GSettings schemas with the native `glib-compile-schemas` (works fine in my tests). As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do require the target `gdk-pixbuf-query-loaders` which is unfortunately a Windows executable. Yet it seems to work fine with Wine, so let's be done with it in the CI instead of requiring manual steps from testers of the CI builds. Then a few `sed` calls are enough to make the path in the produced text file relative instead of absolute (which works fine, again in my tests at least). This means that I don't have to distribute the 2 binaries and the DLLs they depend on anymore. Moreover let's remove the wrapper (but still generate one which just calls GIMP so that we call it from the tree root, where it's much less messy). Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner. After following all instructions, I encountered weird errors. So instead, I just make the win32-nightly job depend on win64-nightly and copy `loaders.cache` from one to another, as it is a platform-independent text file (as long as we provide the same GdkPixbuf loaders on both of course, which we do).
2020-10-02 18:46:32 +08:00
- apt-get install -y --no-install-recommends
python3 binutils-mingw-w64-i686 file
libglib2.0-bin
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
# Package ressources.
- mkdir -p ${GIMP_DISTRIB}
- cp -fr ${GIMP_PREFIX}/etc ${GIMP_DISTRIB}
- cp -fr ${GIMP_PREFIX}/include ${GIMP_DISTRIB}
- cp -fr ${GIMP_PREFIX}/ssl ${GIMP_DISTRIB}
- cp -fr ${GIMP_PREFIX}/share ${GIMP_DISTRIB}
# Package executables.
- mkdir ${GIMP_DISTRIB}/bin
- cp -fr ${GIMP_PREFIX}/bin/gimp*.exe ${GIMP_DISTRIB}/bin/
- mkdir ${GIMP_DISTRIB}/libexec
- cp -fr ${GIMP_PREFIX}/libexec/gimp*.exe ${GIMP_DISTRIB}/libexec/
build: (Windows) glib-compile-schemas and gdk-pixbuf-query-loaders in… … the CI. There are 2 finale steps before finale binary distribution on Windows. We must compile the GSettings XML schema files and register GdkPixbuf loaders (for file format support in the GUI). I used to provide a wrapper to be run inside Windows before first GIMP run. Never did I realize that I can compile the distributed GSettings schemas with the native `glib-compile-schemas` (works fine in my tests). As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do require the target `gdk-pixbuf-query-loaders` which is unfortunately a Windows executable. Yet it seems to work fine with Wine, so let's be done with it in the CI instead of requiring manual steps from testers of the CI builds. Then a few `sed` calls are enough to make the path in the produced text file relative instead of absolute (which works fine, again in my tests at least). This means that I don't have to distribute the 2 binaries and the DLLs they depend on anymore. Moreover let's remove the wrapper (but still generate one which just calls GIMP so that we call it from the tree root, where it's much less messy). Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner. After following all instructions, I encountered weird errors. So instead, I just make the win32-nightly job depend on win64-nightly and copy `loaders.cache` from one to another, as it is a platform-independent text file (as long as we provide the same GdkPixbuf loaders on both of course, which we do).
2020-10-02 18:46:32 +08:00
# Add a wrapper at tree root, less messy than having to look for the
# binary inside bin/, in the middle of all the DLLs.
- echo "bin\gimp-2.99.exe" > ${GIMP_DISTRIB}/gimp.cmd
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
# Package library data and modules.
- mkdir ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/gimp ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/gio ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/gdk-pixbuf-2.0 ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/gegl-0.4 ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/babl-0.1 ${GIMP_DISTRIB}/lib/
- cp -fr ${GIMP_PREFIX}/lib/girepository-1.0 ${GIMP_DISTRIB}/lib/
build: (Windows) glib-compile-schemas and gdk-pixbuf-query-loaders in… … the CI. There are 2 finale steps before finale binary distribution on Windows. We must compile the GSettings XML schema files and register GdkPixbuf loaders (for file format support in the GUI). I used to provide a wrapper to be run inside Windows before first GIMP run. Never did I realize that I can compile the distributed GSettings schemas with the native `glib-compile-schemas` (works fine in my tests). As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do require the target `gdk-pixbuf-query-loaders` which is unfortunately a Windows executable. Yet it seems to work fine with Wine, so let's be done with it in the CI instead of requiring manual steps from testers of the CI builds. Then a few `sed` calls are enough to make the path in the produced text file relative instead of absolute (which works fine, again in my tests at least). This means that I don't have to distribute the 2 binaries and the DLLs they depend on anymore. Moreover let's remove the wrapper (but still generate one which just calls GIMP so that we call it from the tree root, where it's much less messy). Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner. After following all instructions, I encountered weird errors. So instead, I just make the win32-nightly job depend on win64-nightly and copy `loaders.cache` from one to another, as it is a platform-independent text file (as long as we provide the same GdkPixbuf loaders on both of course, which we do).
2020-10-02 18:46:32 +08:00
# I fail to install wine32 inside the Gitlab runner. So instead, I
gitlab-ci: "needs" jobs have to be in a prior stage.
2020-10-02 19:21:21 +08:00
# just reuse the loaders.cache generated in the deps-win64 job as
build: (Windows) glib-compile-schemas and gdk-pixbuf-query-loaders in… … the CI. There are 2 finale steps before finale binary distribution on Windows. We must compile the GSettings XML schema files and register GdkPixbuf loaders (for file format support in the GUI). I used to provide a wrapper to be run inside Windows before first GIMP run. Never did I realize that I can compile the distributed GSettings schemas with the native `glib-compile-schemas` (works fine in my tests). As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do require the target `gdk-pixbuf-query-loaders` which is unfortunately a Windows executable. Yet it seems to work fine with Wine, so let's be done with it in the CI instead of requiring manual steps from testers of the CI builds. Then a few `sed` calls are enough to make the path in the produced text file relative instead of absolute (which works fine, again in my tests at least). This means that I don't have to distribute the 2 binaries and the DLLs they depend on anymore. Moreover let's remove the wrapper (but still generate one which just calls GIMP so that we call it from the tree root, where it's much less messy). Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner. After following all instructions, I encountered weird errors. So instead, I just make the win32-nightly job depend on win64-nightly and copy `loaders.cache` from one to another, as it is a platform-independent text file (as long as we provide the same GdkPixbuf loaders on both of course, which we do).
2020-10-02 18:46:32 +08:00
# they should be the same (text format).
gitlab-ci: "needs" jobs have to be in a prior stage.
2020-10-02 19:21:21 +08:00
- cp ${XDG_DATA_HOME}/crossroad/roads/w64/gimp/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache ${GIMP_DISTRIB}/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
build: (Windows) glib-compile-schemas and gdk-pixbuf-query-loaders in… … the CI. There are 2 finale steps before finale binary distribution on Windows. We must compile the GSettings XML schema files and register GdkPixbuf loaders (for file format support in the GUI). I used to provide a wrapper to be run inside Windows before first GIMP run. Never did I realize that I can compile the distributed GSettings schemas with the native `glib-compile-schemas` (works fine in my tests). As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do require the target `gdk-pixbuf-query-loaders` which is unfortunately a Windows executable. Yet it seems to work fine with Wine, so let's be done with it in the CI instead of requiring manual steps from testers of the CI builds. Then a few `sed` calls are enough to make the path in the produced text file relative instead of absolute (which works fine, again in my tests at least). This means that I don't have to distribute the 2 binaries and the DLLs they depend on anymore. Moreover let's remove the wrapper (but still generate one which just calls GIMP so that we call it from the tree root, where it's much less messy). Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner. After following all instructions, I encountered weird errors. So instead, I just make the win32-nightly job depend on win64-nightly and copy `loaders.cache` from one to another, as it is a platform-independent text file (as long as we provide the same GdkPixbuf loaders on both of course, which we do).
2020-10-02 18:46:32 +08:00
# Generate share/glib-2.0/schemas/gschemas.compiled
- glib-compile-schemas --targetdir=${GIMP_DISTRIB}/share/glib-2.0/schemas ${GIMP_DISTRIB}/share/glib-2.0/schemas
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
# Package needed DLLs only.
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
- python3 build/windows/gitlab-ci/dll_link.py ${GIMP_DISTRIB}/bin/gimp-2.99.exe ${GIMP_PREFIX}/ ${GIMP_DISTRIB}
- python3 build/windows/gitlab-ci/dll_link.py ${GIMP_DISTRIB}/bin/gimp-console-2.99.exe ${GIMP_PREFIX}/ ${GIMP_DISTRIB}
- python3 build/windows/gitlab-ci/dll_link.py ${GIMP_DISTRIB}/bin/gimp-test-clipboard-2.99.exe ${GIMP_PREFIX}/ ${GIMP_DISTRIB}
- python3 build/windows/gitlab-ci/dll_link.py ${GIMP_DISTRIB}/bin/gimptool-2.99.exe ${GIMP_PREFIX}/ ${GIMP_DISTRIB}
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
- for dll in ${GIMP_DISTRIB}/lib/babl-0.1/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gegl-0.4/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gio/modules/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gdk-pixbuf-2.0/2.10.0/loaders/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gimp/2.99/modules/*.dll; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
- for dll in ${GIMP_DISTRIB}/lib/gimp/2.99/plug-ins/*/*.exe; do
build, gitlab-ci: break the native Windows build into 2 jobs. One for dependencies, one for GIMP.
2021-05-05 07:00:39 +08:00
python3 build/windows/gitlab-ci/dll_link.py $dll ${GIMP_PREFIX}/ ${GIMP_DISTRIB};
gitlab, build: Win32 distribution jobs for our CI. The main purpose of these jobs is to only package the strict necessary for a working GIMP under Windows, i.e. getting rid of all unnecessary executables, and inspecting binary dependencies recursively to only package used DLLs. The dll_link.py script is taken from Siril codebase (see commit a86e82a8 on Siril repository, by FlorianBen). This was a very nice idea, and makes for much smaller test archive (Siril is also GPLv3 so licensing is ok for the reuse, also anyway it's just a small independent build script). Moreover having it as a separate job allows to have artifacts with only the finale distribution (artifacts on the build job also have the build directory and the whole prefix, which we want to keep in order to debug when needed). Hopefully I am not missing anything. Siril seems to package more, like various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if these are actually necessary. I could run GIMP fine without these in quick tests, but I guess I'll have to investigate a bit more to figure this out. That's what nightly builds are for, after all, so hopefully people will report if we miss some runtime dependencies.
2020-09-30 01:38:23 +08:00
done
gitlab-ci: "needs" jobs have to be in a prior stage.
2020-10-02 19:21:21 +08:00
needs: ["gimp-win32", "deps-win64"]
ci: Enable nightly flatpak builds To get a nightly flatpak, GNOME project offers a CI template[0] that can be extended instead of having to define everything from scratch. At the core is the "flatpak" job that tries to build the flatpak. If the build finishes succesfully, the result should be available as a CI artifact as a flatpak bundle. The app id is the same as on Flathub. Another part is the "flatpak-nightly" job that publishes the flatpak if the build succeeded. Without this job, the bundle stays only temporarily. This job can and should only be run on the "master" branch. This jobs is started only when the "flatpak" job finishes successfully. Both jobs can be triggered only thorugh schedules[1]. To finish the flatpak nightlies setup, a schedule needs to be set. [0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak [1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
2020-09-07 23:49:37 +08:00
flatpak-nightly:
extends: '.publish_nightly'
stage: distribution
gitlab-ci: fix (again!) the gitlab-ci. Argh! So it turns out that .publish_nightly template uses already an only: key so we cannot use rules: (on the other hand I guess using only: ourselves is alright and concatenate ours and the one in the template). Fixes: > jobs:flatpak-nightly config key may not be used with `rules`: only
2021-05-27 01:58:52 +08:00
only:
variables:
# Custom builds though web GUI, API or schedules.
# I don't use 'rules:' because .publish_nightly template uses an
# 'only:' already which clashes with 'rules:'.
- $GIMP_CI_FLATPAK != null
ci: Enable nightly flatpak builds To get a nightly flatpak, GNOME project offers a CI template[0] that can be extended instead of having to define everything from scratch. At the core is the "flatpak" job that tries to build the flatpak. If the build finishes succesfully, the result should be available as a CI artifact as a flatpak bundle. The app id is the same as on Flathub. Another part is the "flatpak-nightly" job that publishes the flatpak if the build succeeded. Without this job, the bundle stays only temporarily. This job can and should only be run on the "master" branch. This jobs is started only when the "flatpak" job finishes successfully. Both jobs can be triggered only thorugh schedules[1]. To finish the flatpak nightlies setup, a schedule needs to be set. [0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak [1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
2020-09-07 23:49:37 +08:00
needs: ["flatpak"]
dependencies:
- 'flatpak'