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

1110 lines
39 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: Update jobs order Following 5542748779a71ec783c84d652ecddf7628731f8a
2024-03-17 02:38:51 +08:00
# - Linux native CLang build (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: Update jobs order Following 5542748779a71ec783c84d652ecddf7628731f8a
2024-03-17 02:38:51 +08:00
# - Linux native GCC build (rare usefulness)
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
# - Win Aarch64/64/32 native builds (base but slow)
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
# - cppcheck (static code analysis)
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
# - Win Aarch64/64/32 native builds (Inno Windows installer creation)
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
#
# To force step-specific pipelines without waiting for commits and/or
# pipelines, these are the variable you should set:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
# - GIMP_CI_MESON_CLANG: trigger the Debian clang build.
gitlab-ci: Move to Clang in Debian This makes the GEGL code execution a bit faster in Linux.
2024-03-05 01:42:36 +08:00
# - GIMP_CI_MESON_GCC: trigger the Debian gcc build.
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
# - GIMP_CI_RASTER_ICONS: trigger the Debian build without vector icons.
# - GIMP_CI_CROSSROAD_WIN64: trigger the crossroad build for Win 64-bit.
# - GIMP_CI_CROSSROAD_WIN32: trigger the crossroad build for Win 32-bit.
# - GIMP_CI_MSYS2_WIN_AARCH64: trigger the native MSYS2 build for Win Aarch64.
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
# - GIMP_CI_MSYS2_WIN64: trigger the native MSYS2 build for Win 64-bit.
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
# - GIMP_CI_MSYS2_WIN32: trigger the native MSYS2 build for Win 32-bit.
# - GIMP_CI_FLATPAK: trigger the (normally) weekly flatpak build and publishing.
# - GIMP_CI_WIN_INSTALLER: trigger all native MSYS2 builds then creates Inno Windows installer.
# - GIMP_CI_SOURCES: trigger the Debian gcc build and the source tarball job.
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
# - GIMP_CI_CPPCHECK: trigger cppcheck static analysis.
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
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'
devel-docs, gitlab-ci: freeze our requirement updates to Debian 12 bookworm. While Debian testing is the sensible choice for dependency requirements while we are in full-dev mode, now we are getting closer to 3.0 release, and Debian 12 "bookworm" barely got out. If we continue to develop at current pace, GIMP 3.0 should be released before the next stable Debian, so we should not use dependencies unavailable on the latest stable (otherwise GIMP 3.0 won't be distributable soon enough on Debian, nor on Debian derivatives such as Ubuntu, Mint, etc.). This is why we are now basing GIMP dependency requirement on Debian bookworm. We'll likely get back to the next "testing" after GIMP 3.0 release.
2023-06-11 06:30:45 +08:00
image: debian:bookworm
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"
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
ARTIFACTS_SUFFIX: "-x64"
GIMP_PREFIX: "${CI_PROJECT_DIR}/_install${ARTIFACTS_SUFFIX}"
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 ##
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
image-debian-x64:
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_MESON_CLANG != null'
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- if: '$GIMP_CI_MESON_GCC != 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'
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- if: '$GIMP_CI_CROSSROAD_WIN64 != null'
- if: '$GIMP_CI_CROSSROAD_WIN32 != null'
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- if: '$GIMP_CI_SOURCES != null'
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +08:00
- if: '$GIMP_CI_FLATPAK != 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:
gitlab-ci: Set container explicitly to docker Since the latest release of Kaniko, it fails to detect the container runtime it runs within.
2022-04-01 20:43:33 +08:00
- export container=docker
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
- mkdir -p /kaniko/.docker
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
devel-docs, gitlab-ci: freeze our requirement updates to Debian 12 bookworm. While Debian testing is the sensible choice for dependency requirements while we are in full-dev mode, now we are getting closer to 3.0 release, and Debian 12 "bookworm" barely got out. If we continue to develop at current pace, GIMP 3.0 should be released before the next stable Debian, so we should not use dependencies unavailable on the latest stable (otherwise GIMP 3.0 won't be distributable soon enough on Debian, nor on Debian derivatives such as Ubuntu, Mint, etc.). This is why we are now basing GIMP dependency requirement on Debian bookworm. We'll likely get back to the next "testing" after GIMP 3.0 release.
2023-06-11 06:30:45 +08:00
- echo "FROM debian:bookworm" > Dockerfile
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
- echo "RUN apt-get update" >> Dockerfile
- echo "RUN apt-get install -y --no-install-recommends \\" >> Dockerfile
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
# libjxl uses C++ features that require posix threads so we install
# specifically g++-mingw-w64-x86-64-posix and gcc-mingw-w64-x86-64-posix.
# Note that we can't install both the -posix and -win32 versions since
# update gcc-mingw-w64 (25). This is for crossroad builds only
gitlab-ci: one-line per installed package for dependency maintenance. This commit makes no real changes but style. As discussed, this makes it much easier to compare commit diffs, rather than an overlong line where you have to search which package may have been added/removed/changed.
2023-06-06 17:27:05 +08:00
- echo "appstream
at-spi2-core
build-essential
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
cpio
gitlab-ci: one-line per installed package for dependency maintenance. This commit makes no real changes but style. As discussed, this makes it much easier to compare commit diffs, rather than an overlong line where you have to search which package may have been added/removed/changed.
2023-06-06 17:27:05 +08:00
desktop-file-utils
ffmpeg
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
g++-mingw-w64-x86-64-posix
gcc-mingw-w64-x86-64-posix
g++-mingw-w64-i686
gcc-mingw-w64-i686
gitlab-ci: one-line per installed package for dependency maintenance. This commit makes no real changes but style. As discussed, this makes it much easier to compare commit diffs, rather than an overlong line where you have to search which package may have been added/removed/changed.
2023-06-06 17:27:05 +08:00
gettext
ghostscript
gi-docgen
git
glib-networking
gobject-introspection
graphviz
graphviz-dev
hicolor-icon-theme
iso-codes
libaa1-dev
libappstream-glib-dev
libbz2-dev
libcfitsio-dev
libdbus-glib-1-dev
libexif-dev
libgexiv2-dev
libgirepository1.0-dev
libgs-dev
libgtk-3-bin
libgtk-3-dev
libgudev-1.0-dev
libheif-dev
libjson-glib-dev
libjxl-dev
liblcms2-dev
liblzma-dev
libmng-dev
libmypaint-dev
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
libomp-dev
gitlab-ci: one-line per installed package for dependency maintenance. This commit makes no real changes but style. As discussed, this makes it much easier to compare commit diffs, rather than an overlong line where you have to search which package may have been added/removed/changed.
2023-06-06 17:27:05 +08:00
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
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
python3-distutils
python3-docutils
gitlab-ci, build: create Windows installer files with the Linux build. The creation of the BMP welcome images for the Windows installer (part of -Dwindows-installer=true build option) fails in the Windows job. After much debugging, I could run GIMP, yet it was not enough. One of my hypothesis so far is that the environment variables for DLLs won't work, since all the DLLs must be in the same directory as the main binary (though with the WSL thing, I am unsure, maybe it is still supposed to work), which only happens once GIMP is installed. So GIMP runs successfully but not plug-ins. Anyway I wasted too much time working on this and without a local Windows, it just takes too long (mostly testing thanks to the CI) and is frustrating. Let's just move to building both the localization files and the images on the main Debian job (gimp-meson-debian), then use these as dependencies of the win-installer-nightly job, i.e. when building the installer.
2023-06-28 06:24:41 +08:00
python3-gi
gitlab-ci: one-line per installed package for dependency maintenance. This commit makes no real changes but style. As discussed, this makes it much easier to compare commit diffs, rather than an overlong line where you have to search which package may have been added/removed/changed.
2023-06-06 17:27:05 +08:00
python3-pip
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
python3-zstandard
rpm
gitlab-ci: one-line per installed package for dependency maintenance. This commit makes no real changes but style. As discussed, this makes it much easier to compare commit diffs, rather than an overlong line where you have to search which package may have been added/removed/changed.
2023-06-06 17:27:05 +08:00
valac
xauth
xsltproc
xvfb
xz-utils
yelp-tools" >> 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
devel-docs, gitlab-ci: freeze our requirement updates to Debian 12 bookworm. While Debian testing is the sensible choice for dependency requirements while we are in full-dev mode, now we are getting closer to 3.0 release, and Debian 12 "bookworm" barely got out. If we continue to develop at current pace, GIMP 3.0 should be released before the next stable Debian, so we should not use dependencies unavailable on the latest stable (otherwise GIMP 3.0 won't be distributable soon enough on Debian, nor on Debian derivatives such as Ubuntu, Mint, etc.). This is why we are now basing GIMP dependency requirement on Debian bookworm. We'll likely get back to the next "testing" after GIMP 3.0 release.
2023-06-11 06:30:45 +08:00
## GNU/Linux 64-bit CIs (Debian bookworm) ##
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
deps-debian-x64:
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_MESON_CLANG != null'
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- if: '$GIMP_CI_MESON_GCC != 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'
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
- if: '$GIMP_CI_CROSSROAD_WIN64 != null'
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- if: '$GIMP_CI_CROSSROAD_WIN32 != null'
- if: '$GIMP_CI_SOURCES != null'
- if: '$GIMP_CI_FLATPAK != null'
gitlab-ci: Move to Clang in Debian This makes the GEGL code execution a bit faster in Linux.
2024-03-05 01:42:36 +08:00
variables:
CC: "clang"
CXX: "clang++"
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
.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:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- "_install${ARTIFACTS_SUFFIX}"
- _babl/_build${ARTIFACTS_SUFFIX}
- _gegl/_build${ARTIFACTS_SUFFIX}
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
before_script:
gitlab-ci: use the last tagged releases of babl and GEGL for deps-debian-x64 too. This is similar code to what I added for the Windows builds, except that here it's because deps-debian-x64 will also end up feeding dev-docs job too. Right now our tagged build of GIMP produces docs for unstable versions of babl and GEGL.
2024-02-19 19:06:15 +08:00
- if [ "$CI_COMMIT_TAG" != "" ]; then
repo=https://gitlab.gnome.org/GNOME/babl.git;
babl_tag=$(git ls-remote --tags --exit-code --refs "$repo" |
grep -oi "BABL_[0-9]*_[0-9]*_[0-9]*" |
sort --version-sort | tail -1);
babl_branch="--branch=$babl_tag";
repo=https://gitlab.gnome.org/GNOME/gegl.git;
gegl_tag=$(git ls-remote --tags --exit-code --refs "$repo" |
grep -oi "GEGL_[0-9]*_[0-9]*_[0-9]*" |
sort --version-sort | tail -1);
gegl_branch="--branch=$gegl_tag";
fi
- git clone $babl_branch --depth=${GIT_DEPTH} https://gitlab.gnome.org/GNOME/babl.git _babl
- git clone $gegl_branch --depth=${GIT_DEPTH} https://gitlab.gnome.org/GNOME/gegl.git _gegl
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- export PATH="$GIMP_PREFIX/bin:$PATH"
gitlab-ci, build: Unify variables following gimp-web-devel We should avoid disparity with the build instructions since contributors will look at the CI files. See: Infrastructure/gimp-web-devel!54 and Infrastructure/gimp-web-devel!65
2024-04-02 04:12:08 +08:00
- gcc -print-multi-os-directory | grep . && LIB_DIR=$(gcc -print-multi-os-directory | sed 's/\.\.\///g') || LIB_DIR="lib"
- gcc -print-multiarch | grep . && LIB_SUBDIR=$(echo $(gcc -print-multiarch)'/')
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- export PKG_CONFIG_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}pkgconfig${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH}"
- export LD_LIBRARY_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
- export XDG_DATA_DIRS="${GIMP_PREFIX}/share:/usr/share${XDG_DATA_DIRS:+:$XDG_DATA_DIRS}"
- export GI_TYPELIB_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}girepository-1.0${GI_TYPELIB_PATH:+:$GI_TYPELIB_PATH}"
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
script:
gitlab-ci: Move to Clang in Debian This makes the GEGL code execution a bit faster in Linux.
2024-03-05 01:42:36 +08:00
- mkdir -p "$APT_CACHE"
- apt-get install -y --no-install-recommends -o dir::cache::archives="$APT_CACHE"
clang
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- mkdir _babl/_build${ARTIFACTS_SUFFIX} && cd _babl/_build${ARTIFACTS_SUFFIX}
- meson setup .. -Dprefix="${GIMP_PREFIX}"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- ninja && ninja install
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- mkdir ../../_gegl/_build${ARTIFACTS_SUFFIX} && cd ../../_gegl/_build${ARTIFACTS_SUFFIX}
- meson setup .. -Dprefix="${GIMP_PREFIX}"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- ninja && ninja install
needs: ["image-debian-x64"]
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- deps-debian-x64
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
paths:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- "_build${ARTIFACTS_SUFFIX}"
- "_install${ARTIFACTS_SUFFIX}"
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
before_script:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- export PATH="$GIMP_PREFIX/bin:$PATH"
gitlab-ci, build: Unify variables following gimp-web-devel We should avoid disparity with the build instructions since contributors will look at the CI files. See: Infrastructure/gimp-web-devel!54 and Infrastructure/gimp-web-devel!65
2024-04-02 04:12:08 +08:00
- gcc -print-multi-os-directory | grep . && LIB_DIR=$(gcc -print-multi-os-directory | sed 's/\.\.\///g') || LIB_DIR="lib"
- gcc -print-multiarch | grep . && LIB_SUBDIR=$(echo $(gcc -print-multiarch)'/')
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- export PKG_CONFIG_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}pkgconfig${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH}"
- export LD_LIBRARY_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
- export XDG_DATA_DIRS="${GIMP_PREFIX}/share:/usr/share${XDG_DATA_DIRS:+:$XDG_DATA_DIRS}"
- export GI_TYPELIB_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}girepository-1.0${GI_TYPELIB_PATH:+:$GI_TYPELIB_PATH}"
meson: moving away from meson subprojects in favor of git submodules. Meson subprojects just have too many problems and limitations and I can foresee the maintenance headache and the future incoming false-positive bug reports if we start using meson subprojects. Comparing to the simplicity of git submodule which also has much better notifications to help people understand when the submodule is not in sync and how to remedy to it. See commit gimp-data@c364adb explaining the main reasons in detail.
2024-03-01 22:15:18 +08:00
- git submodule update --init
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
needs: ["deps-debian-x64"]
gimp-debian-x64:
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: try to fix the CI for releases (and other CI pipelines).
2022-08-20 17:17:44 +08:00
# On commits and merge requests.
- 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: fix the schedule pipeline for our nightly Windows installer. This should fix: > 'win-installer-nightly' job needs 'gimp-meson-debian' job, but 'gimp-meson-debian' is not in any previous stage
2023-08-07 20:32:00 +08:00
# Custom builds though web GUI, API or schedules.
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +08:00
- if: '$GIMP_CI_FLATPAK != null'
gitlab-ci: try to fix the CI for releases (and other CI pipelines).
2022-08-20 17:17:44 +08:00
# On releases.
- if: '$CI_COMMIT_TAG != null'
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.
gitlab-ci: Move to Clang in Debian This makes the GEGL code execution a bit faster in Linux.
2024-03-05 01:42:36 +08:00
- if: '$GIMP_CI_MESON_CLANG != null'
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
- if: '$GIMP_CI_CROSSROAD_WIN64 != null'
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- if: '$GIMP_CI_CROSSROAD_WIN32 != 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: Move to Clang in Debian This makes the GEGL code execution a bit faster in Linux.
2024-03-05 01:42:36 +08:00
variables:
CC: "clang"
CXX: "clang++"
Update gitlab-ci
2019-08-09 22:18:43 +08:00
script:
gitlab-ci: Move to Clang in Debian This makes the GEGL code execution a bit faster in Linux.
2024-03-05 01:42:36 +08:00
- mkdir -p "$APT_CACHE"
- apt-get install -y --no-install-recommends -o dir::cache::archives="$APT_CACHE"
clang
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- mkdir -p "_build${ARTIFACTS_SUFFIX}" && cd "_build${ARTIFACTS_SUFFIX}"
- meson setup .. -Dprefix="${GIMP_PREFIX}"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
-Dgi-docgen=enabled
-Dg-ir-doc=true
- ninja && ninja test
gitlab-ci: make gimp-meson-debian more robust to source updates. The `ninja dist` step fails with: > ERROR: Repository has uncommitted changes that will not be included in the dist tarball > Use --allow-dirty to ignore the warning and proceed anyway > FAILED: meson-dist > /usr/bin/meson dist Astonishingly if I run a `git diff` (or git status) in the CI, I saw no changes and the dist suddenly succeeded. When I remove it, it fails again. And of course, locally it's alright. No way to diagnose! Anyway it's not a bad idea to leave some diagnostic logs in the CI so here we go, properly outputting the diff and exiting the job with an error when there is a diff. Because anyway, there should be none. It would mean that there is likely some issue in versionned generated files.
2022-08-02 05:17:00 +08:00
# The src should not be changed by the build. If it is, something is
# wrong. Let's print out the diff for debugging in such case, and
# exit to fail the CI.
- if [ $(git diff |wc -l) -ne 0 ]; then
git diff;
exit 1;
fi
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- ninja dist && ninja install
gitlab-ci: Use JUnit reports from Meson Meson has been generating Junit XML files of its test results since 0.55, so we can use that to show the test results in the GitLab UI.
2023-05-24 06:38:00 +08:00
artifacts:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
gitlab-ci: Use JUnit reports from Meson Meson has been generating Junit XML files of its test results since 0.55, so we can use that to show the test results in the GitLab UI.
2023-05-24 06:38:00 +08:00
when: always
reports:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
junit: "_build${ARTIFACTS_SUFFIX}/meson-logs/testlog.junit.xml"
gitlab-ci: Use JUnit reports from Meson Meson has been generating Junit XML files of its test results since 0.55, so we can use that to show the test results in the GitLab UI.
2023-05-24 06:38:00 +08:00
paths:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- "_build${ARTIFACTS_SUFFIX}/config.h"
- "_build${ARTIFACTS_SUFFIX}/meson-logs"
- "_build${ARTIFACTS_SUFFIX}/meson-dist"
- "_build${ARTIFACTS_SUFFIX}/devel-docs"
- "_build${ARTIFACTS_SUFFIX}/build/flatpak/"
- "_install${ARTIFACTS_SUFFIX}"
Update gitlab-ci
2019-08-09 22:18:43 +08:00
gitlab-ci: Move to Clang in Debian This makes the GEGL code execution a bit faster in Linux.
2024-03-05 01:42:36 +08:00
gimp-debian-gcc:
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).
gitlab-ci: Move to Clang in Debian This makes the GEGL code execution a bit faster in Linux.
2024-03-05 01:42:36 +08:00
- 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
gitlab-ci: test a CLang build.
2020-01-03 07:19:10 +08:00
script:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- mkdir -p _build${ARTIFACTS_SUFFIX} && cd _build${ARTIFACTS_SUFFIX}
- meson setup .. -Dprefix="${GIMP_PREFIX}"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- ninja && ninja test
gitlab-ci: test a CLang build.
2020-01-03 07:19:10 +08:00
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
gimp-debian-raster-icons:
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
rules:
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_RASTER_ICONS != null'
extends: .gimp-debian-base
script:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- mkdir -p _build${ARTIFACTS_SUFFIX} && cd _build${ARTIFACTS_SUFFIX}
- meson setup .. -Dprefix="${GIMP_PREFIX}"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
-Dvector-icons=false
- ninja && ninja test
build: testing a Windows/Aarch64 build. Note: the additional `rm` call was done for this error: > + mv _install-arm64 /home/SYSTEM > mv: cannot move '_install-arm64' to '/home/SYSTEM/_install-arm64': Directory not empty I guess the home directory is not properly wiped-out between runs, which is not a huge problem as long as the runner is private to our project. Let's clean things ourselves.
2023-09-28 19:55:38 +08:00
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +08:00
packaging-flatpak-x64:
# See: https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak
# XXX This job is mostly the same as .flatpak job of
# flatpak_ci_initiative.yml so far, except that we removed the
# automatic tests since rebuilding plug-ins was not working and
# one of the test (save-and-export) requires plug-ins to be built.
image: 'quay.io/gnome_infrastructure/gnome-runtime-images:gnome-master'
stage: packaging
dependencies:
- gimp-debian-x64
tags:
- flatpak
needs: ["gimp-debian-x64"]
rules:
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_FLATPAK != null'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Flatpak package.*/'
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"
before_script:
# Report the installed versions of the runtime
- flatpak info org.gnome.Platform
- flatpak info org.gnome.Sdk
gitlab-ci, build: Move to Clang in Flatpak (mostly) In our efforts to use Clang, now the nightly (in fact weekly) flatpak is built with Clang too, not only GIMP but also the dependencies. * However, not aalib. We welcome fixes regarding this cursed lib. Additionally, updated some build options from some deps.
2024-03-15 00:03:45 +08:00
# Install LLVM/Clang
- flatpak remote-add --if-not-exists --user flathub https://dl.flathub.org/repo/flathub.flatpakrepo
- flatpak install --user flathub org.freedesktop.Sdk.Extension.llvm17 -y
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +08:00
# Print the date, since appstream depends on local timezone
- date && date -u
# Get pre-configured manifest from Debian job
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- cp _build${ARTIFACTS_SUFFIX}/build/flatpak/*json build/flatpak/
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +08:00
# GNOME script to customize the manifest
- rewrite-flatpak-manifest ${MANIFEST_PATH} ${FLATPAK_MODULE} ${CONFIG_OPTS}
script:
# Build deps and GIMP
# (Our script is too long for Gitlab and no complete output would be collected
# To make debugging actually possible, let's save logs as a file.)
- flatpak-builder --user --disable-rofiles-fuse flatpak_app --repo=repo ${BRANCH:+--default-branch=$BRANCH} ${MANIFEST_PATH}
2>&1 | tee flatpak-builder.log
# Generate a Flatpak bundle
- flatpak build-bundle repo ${BUNDLE} --runtime-repo=${RUNTIME_REPO} ${APP_ID} ${BRANCH}
- tar cf repo.tar repo/
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
gitlab-ci: Expose job artifacts in UI Makes a bit easier to newcomers download the main artifacts in MRs. (This feature doesn't support variables or wildcards in paths)
2024-04-10 08:24:13 +08:00
expose_as: 'Linux flatpak'
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +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.
gitlab-ci: Expose job artifacts in UI Makes a bit easier to newcomers download the main artifacts in MRs. (This feature doesn't support variables or wildcards in paths)
2024-04-10 08:24:13 +08:00
- "gimp-git.flatpak"
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +08:00
- 'repo.tar'
gitlab-ci: Expose job artifacts in UI Makes a bit easier to newcomers download the main artifacts in MRs. (This feature doesn't support variables or wildcards in paths)
2024-04-10 08:24:13 +08:00
- '.flatpak-builder/build/gimp/_flatpak_build/meson-logs/meson-log.txt'
- '.flatpak-builder/build/gimp/_flatpak_build/meson-logs/testlog.txt'
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +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'
build: testing a Windows/Aarch64 build. Note: the additional `rm` call was done for this error: > + mv _install-arm64 /home/SYSTEM > mv: cannot move '_install-arm64' to '/home/SYSTEM/_install-arm64': Directory not empty I guess the home directory is not properly wiped-out between runs, which is not a huge problem as long as the runner is private to our project. Let's clean things ourselves.
2023-09-28 19:55:38 +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 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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
deps-win-x64-cross:
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
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +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
variables:
XDG_CACHE_HOME: "$CI_PROJECT_DIR/.cache/"
XDG_DATA_HOME: "$CI_PROJECT_DIR/.local/share/"
gitlab-ci: using the 'posix_local' installation scheme for Python. Python 3.10 introduced sysconfig.get_default_scheme() and somehow Debian decided it was a good idea to move from the 'posix_prefix' to the 'posix_local' scheme. See: https://lists.debian.org/debian-python/2022/03/msg00039.html The main issue with this scheme is that it adds a local/ subdirectory to the set --prefix. As a consequence, with --prefix=~/.local/, scripts are installed in ~/.local/local/bin/ (instead of proper ~/.local/bin/), data are now in ~/.local/local/share/ and so on. As expected, this broke a lot of CIs for a lot of projects, as well as a lot of custom scripts, usage of Python in virtualenv (this later case seems like it is fixed by special-casing it in Python 3.11), flatpak, etc. Setting DEB_PYTHON_INSTALL_LAYOUT environment variable to "deb" solves this by changing the default scheme. This URL is also useful to understand the issue: https://askubuntu.com/questions/1406304/virtualenv-installs-envs-into-local-bin-instead-of-bin As a side note, Debian is not the only one which made the mistake. Fedora also did the same thing (and they have also their own different environment variable to handle this): https://bugzilla.redhat.com/show_bug.cgi?id=2026979
2023-01-07 01:33:17 +08:00
# Needed because by default, Debian has now changed
# "sysconfig.get_default_scheme()" from "posix_prefix" to "posix_local" which
# adds a local/ folder to the install prefix of setup.py. This environment
# variable overrides this behavior.
DEB_PYTHON_INSTALL_LAYOUT: "deb"
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
APT_CACHE: "${CI_PROJECT_DIR}/apt-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
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
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
- mkdir -p "$APT_CACHE"
- apt-get install -y --no-install-recommends -o dir::cache::archives="$APT_CACHE"
wine
wine64
gitlab-ci: crossroad repository was moved. Crossroad repo was finally moved to Freedesktop. See: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/477 This should avoid the too many failures we have lately on TuxFamily infrastructure (and also gives a proper bug tracker for Crossroad). I am very thankful to TuxFamily for all these years! :-) Let's not be said that I moved the repo because I don't like this friendly FLOSS host anymore. I just needed something different for Crossroad project now.
2023-08-07 21:14:27 +08:00
- git clone --depth=${GIT_DEPTH} https://gitlab.freedesktop.org/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: 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"
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- crossroad w64 gimp --run="build/windows/gitlab-ci/1_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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
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/
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- _deps/_babl/_build-x64-cross/
- _deps/_gegl/_build-x64-cross/
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
needs: ["image-debian-x64"]
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
gimp-win-x64-cross:
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
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- deps-win-x64-cross
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
- gimp-debian-x64
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
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
before_script:
meson: moving away from meson subprojects in favor of git submodules. Meson subprojects just have too many problems and limitations and I can foresee the maintenance headache and the future incoming false-positive bug reports if we start using meson subprojects. Comparing to the simplicity of git submodule which also has much better notifications to help people understand when the submodule is not in sync and how to remedy to it. See commit gimp-data@c364adb explaining the main reasons in detail.
2024-03-01 22:15:18 +08:00
- git submodule update --init
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
# So that we can use gimp-console from gimp-debian-x64 project.
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- GIMP_APP_VERSION=$(grep GIMP_APP_VERSION _build${ARTIFACTS_SUFFIX}/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/')
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
- mkdir bin
- echo "#!/bin/sh" > bin/gimp-console-$GIMP_APP_VERSION
gitlab-ci, build: Unify variables following gimp-web-devel We should avoid disparity with the build instructions since contributors will look at the CI files. See: Infrastructure/gimp-web-devel!54 and Infrastructure/gimp-web-devel!65
2024-04-02 04:12:08 +08:00
- gcc -print-multi-os-directory | grep . && LIB_DIR=$(gcc -print-multi-os-directory | sed 's/\.\.\///g') || LIB_DIR="lib"
- gcc -print-multiarch | grep . && LIB_SUBDIR=$(echo $(gcc -print-multiarch)'/')
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- echo export LD_LIBRARY_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" >> bin/gimp-console-$GIMP_APP_VERSION
- echo export GI_TYPELIB_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}girepository-1.0${GI_TYPELIB_PATH:+:$GI_TYPELIB_PATH}" >> bin/gimp-console-$GIMP_APP_VERSION
- echo "${GIMP_PREFIX}/bin/gimp-console-$GIMP_APP_VERSION \"\$@\"" >> bin/gimp-console-$GIMP_APP_VERSION
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
- chmod u+x bin/gimp-console-$GIMP_APP_VERSION
- export PATH="`pwd`/bin:$PATH"
# For crossroad
- export PATH="`pwd`/.local/bin:$PATH"
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
script:
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
- crossroad w64 gimp --run="build/windows/gitlab-ci/2_build-gimp-crossroad.sh"
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
needs: ["deps-win-x64-cross", "gimp-debian-x64"]
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
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:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- _build-x64-cross/
- _install-x64-cross/
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
packaging-win-x64-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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
# On commits except tags.
- if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_TAG == null'
gitlab-ci: Expose job artifacts in UI Makes a bit easier to newcomers download the main artifacts in MRs. (This feature doesn't support variables or wildcards in paths)
2024-04-10 08:24:13 +08:00
# On merge requests.
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_CROSSROAD_WIN64 != null'
stage: packaging
dependencies:
- gimp-win-x64-cross
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:
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
BUILD_TYPE: "CI_CROSS"
CROSSROAD_PLATFORM: "w64"
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
expire_in: 2 days
gitlab-ci: Expose job artifacts in UI Makes a bit easier to newcomers download the main artifacts in MRs. (This feature doesn't support variables or wildcards in paths)
2024-04-10 08:24:13 +08:00
expose_as: 'Windows zip'
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:
gitlab-ci: Expose job artifacts in UI Makes a bit easier to newcomers download the main artifacts in MRs. (This feature doesn't support variables or wildcards in paths)
2024-04-10 08:24:13 +08:00
- gimp-x64/
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
- done-dll.list
before_script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- apt-get update
- apt-get install -y --no-install-recommends
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
binutils
binutils-mingw-w64-x86-64
file
libglib2.0-bin
python3
script:
- bash -x build/windows/gitlab-ci/3_package-gimp-uni_base.sh
- cd gimp-x64
- bash -x ../build/windows/gitlab-ci/3_package-gimp-uni_sym.sh
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
needs: ["gimp-win-x64-cross"]
## WINDOWS 32-bit CI (cross-build crossroad) ##
deps-win-x86-cross:
rules:
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_CROSSROAD_WIN32 != null'
stage: dependencies
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
image: $CI_REGISTRY_IMAGE:build-debian-latest
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
variables:
XDG_CACHE_HOME: "$CI_PROJECT_DIR/.cache/"
XDG_DATA_HOME: "$CI_PROJECT_DIR/.local/share/"
DEB_PYTHON_INSTALL_LAYOUT: "deb"
cache:
paths:
- .cache/crossroad/
- apt-cache
before_script:
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
- apt-get update
- mkdir -p "$APT_CACHE"
- apt-get install -y --no-install-recommends -o dir::cache::archives="$APT_CACHE"
wine
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- git clone --depth=${GIT_DEPTH} https://gitlab.freedesktop.org/crossroad/crossroad.git
- cd crossroad
- ./setup.py install --prefix=`pwd`/../.local
- cd ..
- export PATH="`pwd`/.local/bin:$PATH"
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- crossroad w32 gimp --run="build/windows/gitlab-ci/1_build-deps-crossroad.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 2 hours
paths:
- .local/
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- _deps/_babl/_build-x86-cross/
- _deps/_gegl/_build-x86-cross/
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
needs: ["image-debian-x64"]
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
gimp-win-x86-cross:
rules:
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_CROSSROAD_WIN32 != null'
stage: gimp
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
image: $CI_REGISTRY_IMAGE:build-debian-latest
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
dependencies:
- deps-win-x86-cross
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
- deps-win-x64-cross
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
- gimp-debian-x64
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
variables:
XDG_CACHE_HOME: "$CI_PROJECT_DIR/.cache/"
XDG_DATA_HOME: "$CI_PROJECT_DIR/.local/share/"
cache:
paths:
- .cache/crossroad/
- apt-cache
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
before_script:
meson: moving away from meson subprojects in favor of git submodules. Meson subprojects just have too many problems and limitations and I can foresee the maintenance headache and the future incoming false-positive bug reports if we start using meson subprojects. Comparing to the simplicity of git submodule which also has much better notifications to help people understand when the submodule is not in sync and how to remedy to it. See commit gimp-data@c364adb explaining the main reasons in detail.
2024-03-01 22:15:18 +08:00
- git submodule update --init
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
# So that we can use gimp-console from gimp-debian-x64 project.
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- GIMP_APP_VERSION=$(grep GIMP_APP_VERSION _build${ARTIFACTS_SUFFIX}/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/')
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
- mkdir bin
- echo "#!/bin/sh" > bin/gimp-console-$GIMP_APP_VERSION
gitlab-ci, build: Unify variables following gimp-web-devel We should avoid disparity with the build instructions since contributors will look at the CI files. See: Infrastructure/gimp-web-devel!54 and Infrastructure/gimp-web-devel!65
2024-04-02 04:12:08 +08:00
- gcc -print-multi-os-directory | grep . && LIB_DIR=$(gcc -print-multi-os-directory | sed 's/\.\.\///g') || LIB_DIR="lib"
- gcc -print-multiarch | grep . && LIB_SUBDIR=$(echo $(gcc -print-multiarch)'/')
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- echo export LD_LIBRARY_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" >> bin/gimp-console-$GIMP_APP_VERSION
- echo export GI_TYPELIB_PATH="${GIMP_PREFIX}/${LIB_DIR}/${LIB_SUBDIR}girepository-1.0${GI_TYPELIB_PATH:+:$GI_TYPELIB_PATH}" >> bin/gimp-console-$GIMP_APP_VERSION
- echo "${GIMP_PREFIX}/bin/gimp-console-$GIMP_APP_VERSION \"\$@\"" >> bin/gimp-console-$GIMP_APP_VERSION
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
- chmod u+x bin/gimp-console-$GIMP_APP_VERSION
- export PATH="`pwd`/bin:$PATH"
# For crossroad
- export PATH="`pwd`/.local/bin:$PATH"
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
script:
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
- crossroad w32 gimp --run="build/windows/gitlab-ci/2_build-gimp-crossroad.sh"
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
needs: ["deps-win-x86-cross", "deps-win-x64-cross", "gimp-debian-x64"]
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 1 day
paths:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- _build-x86-cross/
- _install-x86-cross/
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
packaging-win-x86-nightly:
rules:
# Custom builds only (web GUI, API or schedules).
- if: '$GIMP_CI_CROSSROAD_WIN32 != null'
stage: packaging
dependencies:
- gimp-win-x86-cross
variables:
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
BUILD_TYPE: "CI_CROSS"
CROSSROAD_PLATFORM: "w32"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
XDG_DATA_HOME: "$CI_PROJECT_DIR/.local/share/"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 2 days
paths:
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
- gimp-x86
- done-dll.list
before_script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- apt-get update
- apt-get install -y --no-install-recommends
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
binutils
binutils-mingw-w64-i686
file
libglib2.0-bin
python3
script:
- bash -x build/windows/gitlab-ci/3_package-gimp-uni_base.sh
- cd gimp-x86
- bash -x ../build/windows/gitlab-ci/3_package-gimp-uni_sym.sh
needs: ["gimp-win-x86-cross"]
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
## WINDOWS Aarch64 CI (native MSYS2) ##
deps-win-a64:
rules:
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_MSYS2_WIN_AARCH64 != null'
- if: '$GIMP_CI_WIN_INSTALLER != null'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
stage: dependencies
variables:
gitlab-ci, build/windows: Make Deps script compatible with Local-Native build The local builds now can use the same script of CI for sake of time. The compatibility layer is very simple and makes the script more used/tested, therefore more reliable. Also, remove some redundacy on the code for better maintenance.
2023-12-10 23:49:07 +08:00
BUILD_TYPE: "CI_NATIVE"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
MSYSTEM: "CLANGARM64"
CHERE_INVOKING: "yes"
tags:
- windows-aarch64
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
before_script:
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
# C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
script:
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
# Verification to prevent the job from failing because stuck pacman (ARM only),
# since our runner keeps the status of the MSYS2 installation between jobs
- $stuck = Test-Path -Path "C:\msys64\var\lib\pacman\db.lck" -PathType Leaf
- if ($stuck -eq "True") {
gitlab-ci: clarify multi-command shell block. Two shell commands got merged as one line. This seems to work fine on hmartinez82's runner, unlike on our new runners. Anyway it is likely good practice to clearly separate the commands. Fixing: $ if ($stuck -eq "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck" Write-Output "Cleaned previous stuck pacman" } Remove-Item : A positional parameter cannot be found that accepts argument 'Write-Output'. At line:279 char:26 + ... q "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (:) [Remove-Item], ParameterBindingException + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
2024-02-08 05:42:57 +08:00
Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck";
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
Write-Output "Cleaned previous stuck pacman" }
gitlab-ci: terminate all msys2 related processes before Windows/Aarch64 jobs. This is the command suggest by MSYS2 developers here: https://github.com/msys2/MSYS2-packages/issues/4340#issuecomment-1887695290 They also say to run it outside the MSYS2 environment, which is why it's in the CI rules, not in the shell script. Honestly at this point, it feels like we are just stacking weird workaround to get it to fail not too often. ;-(
2024-02-08 22:46:19 +08:00
- taskkill /F /FI "MODULES eq msys-2.0.dll"
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
- Start-Job -ScriptBlock{sleep 90; taskkill /t /F /IM "pacman.exe"}
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/1_build-deps-msys2.sh"
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
retry: 2
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 2 hours
paths:
- _install-a64
needs: []
gimp-win-a64:
rules:
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_MSYS2_WIN_AARCH64 != null'
- if: '$GIMP_CI_WIN_INSTALLER != null'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
stage: gimp
variables:
gitlab-ci, build/windows: Make Build script compatible with Local-Native build The local builds now can use the same script of CI for sake of time. The compatibility layer is very simple and makes the script more used/tested, therefore more reliable.
2023-12-17 08:22:21 +08:00
BUILD_TYPE: "CI_NATIVE"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
MSYSTEM: "CLANGARM64"
CHERE_INVOKING: "yes"
tags:
- windows-aarch64
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
before_script:
# C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
script:
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
- $stuck = Test-Path -Path "C:\msys64\var\lib\pacman\db.lck" -PathType Leaf
- if ($stuck -eq "True") {
gitlab-ci: clarify multi-command shell block. Two shell commands got merged as one line. This seems to work fine on hmartinez82's runner, unlike on our new runners. Anyway it is likely good practice to clearly separate the commands. Fixing: $ if ($stuck -eq "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck" Write-Output "Cleaned previous stuck pacman" } Remove-Item : A positional parameter cannot be found that accepts argument 'Write-Output'. At line:279 char:26 + ... q "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (:) [Remove-Item], ParameterBindingException + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
2024-02-08 05:42:57 +08:00
Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck";
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
Write-Output "Cleaned previous stuck pacman" }
gitlab-ci: terminate all msys2 related processes before Windows/Aarch64 jobs. This is the command suggest by MSYS2 developers here: https://github.com/msys2/MSYS2-packages/issues/4340#issuecomment-1887695290 They also say to run it outside the MSYS2 environment, which is why it's in the CI rules, not in the shell script. Honestly at this point, it feels like we are just stacking weird workaround to get it to fail not too often. ;-(
2024-02-08 22:46:19 +08:00
- taskkill /F /FI "MODULES eq msys-2.0.dll"
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
- Start-Job -ScriptBlock{sleep 90; taskkill /t /F /IM "pacman.exe"}
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/2_build-gimp-msys2.sh"
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
retry: 2
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 1 day
paths:
- _install-a64
- _build-a64/build/windows/installer/
- _build-a64/meson-*/
gitlab-ci: fix dist-installer-weekly job. Since dist-installer-weekly doesn't depend on gimp-debian-x64 anymore, we need to grab the config.h from one of the other dependencies. Let's use the one from gimp-win-a64 (though it could have been any other Windows build job). Fixes: > Get-Content : Cannot bind argument to parameter 'Path' because it is an empty string. > At C:\_r\_builds\vJWzEqDv\0\GNOME\gimp\build\windows\gitlab-ci\4_dist-gimp-inno.ps1:13 char:39 > + $GIMP_VERSION = Get-Content -Path "$CONFIG_PATH" | Select ... > + ~~~~~~~~~~~~~~ > + CategoryInfo : InvalidData: (:) [Get-Content], ParameterBindingValidationException > + FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.GetC > ontentCommand
2024-03-27 10:51:45 +08:00
# Needed by 4_dist-gimp-inno.ps1 in dist-installer-weekly
- _build-a64/config.h
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
cache:
paths:
- _ccache/
needs: ["deps-win-a64"]
packaging-win-a64:
rules:
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_WIN_INSTALLER != null'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
stage: packaging
variables:
gitlab-ci, build: BUILD_TYPE not set for packaging-win-a64 job. Aaaargh! I think this was the main issue which would explain why the problem was mostly happening on the packaging job. In this job, we were still consistently calling `pacman --noconfirm -Suy` (i.e.g "Synchronizing package databases") which we had stopped to do for the CI builds as that was highly increasing chances of locking pacman's process.
2024-02-09 02:26:21 +08:00
BUILD_TYPE: "CI_NATIVE"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
MSYSTEM: "CLANGARM64"
CHERE_INVOKING: "yes"
tags:
- windows-aarch64
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
before_script:
# C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
script:
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
- $stuck = Test-Path -Path "C:\msys64\var\lib\pacman\db.lck" -PathType Leaf
- if ($stuck -eq "True") {
gitlab-ci: clarify multi-command shell block. Two shell commands got merged as one line. This seems to work fine on hmartinez82's runner, unlike on our new runners. Anyway it is likely good practice to clearly separate the commands. Fixing: $ if ($stuck -eq "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck" Write-Output "Cleaned previous stuck pacman" } Remove-Item : A positional parameter cannot be found that accepts argument 'Write-Output'. At line:279 char:26 + ... q "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (:) [Remove-Item], ParameterBindingException + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
2024-02-08 05:42:57 +08:00
Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck";
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
Write-Output "Cleaned previous stuck pacman" }
gitlab-ci: terminate all msys2 related processes before Windows/Aarch64 jobs. This is the command suggest by MSYS2 developers here: https://github.com/msys2/MSYS2-packages/issues/4340#issuecomment-1887695290 They also say to run it outside the MSYS2 environment, which is why it's in the CI rules, not in the shell script. Honestly at this point, it feels like we are just stacking weird workaround to get it to fail not too often. ;-(
2024-02-08 22:46:19 +08:00
- taskkill /F /FI "MODULES eq msys-2.0.dll"
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
- Start-Job -ScriptBlock{sleep 90; taskkill /t /F /IM "pacman.exe"}
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/3_package-gimp-uni_base.sh"
- cd gimp-a64
- C:\msys64\usr\bin\bash -lc "bash -x ../build/windows/gitlab-ci/3_package-gimp-uni_sym.sh"
gitlab-ci: Tweak CI to avoid stuck win-a64 jobs 'clangarm64' pacman is getting stuck and killing it is the only "solution" before any patch by the MSYS2 folks.
2024-01-16 18:35:48 +08:00
retry: 2
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 1 day
paths:
- gimp-a64
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
# Just passing-through splash and language files for the Windows installer.
- _build-a64/build/windows/installer/
gitlab-ci: fix dist-installer-weekly job. Since dist-installer-weekly doesn't depend on gimp-debian-x64 anymore, we need to grab the config.h from one of the other dependencies. Let's use the one from gimp-win-a64 (though it could have been any other Windows build job). Fixes: > Get-Content : Cannot bind argument to parameter 'Path' because it is an empty string. > At C:\_r\_builds\vJWzEqDv\0\GNOME\gimp\build\windows\gitlab-ci\4_dist-gimp-inno.ps1:13 char:39 > + $GIMP_VERSION = Get-Content -Path "$CONFIG_PATH" | Select ... > + ~~~~~~~~~~~~~~ > + CategoryInfo : InvalidData: (:) [Get-Content], ParameterBindingValidationException > + FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.GetC > ontentCommand
2024-03-27 10:51:45 +08:00
# Needed by 4_dist-gimp-inno.ps1 in dist-installer-weekly
- _build-a64/config.h
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- done-dll.list
needs: ["gimp-win-a64"]
## WINDOWS x86_64 CI (native MSYS2) ##
deps-win-x64:
rules:
# 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'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
stage: dependencies
variables:
gitlab-ci, build/windows: Make Deps script compatible with Local-Native build The local builds now can use the same script of CI for sake of time. The compatibility layer is very simple and makes the script more used/tested, therefore more reliable. Also, remove some redundacy on the code for better maintenance.
2023-12-10 23:49:07 +08:00
BUILD_TYPE: "CI_NATIVE"
gitlab-ci, build: Move to Clang in Windows (native) This makes possible to use the Universal C library provided by Microsoft.
2024-03-05 01:47:14 +08:00
MSYSTEM: "CLANG64"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
CHERE_INVOKING: "yes"
tags:
- win32-ps
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
before_script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/1_build-deps-msys2.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 2 hours
paths:
- _install-x64
needs: []
gimp-win-x64:
rules:
# 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'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
stage: gimp
variables:
gitlab-ci, build/windows: Make Build script compatible with Local-Native build The local builds now can use the same script of CI for sake of time. The compatibility layer is very simple and makes the script more used/tested, therefore more reliable.
2023-12-17 08:22:21 +08:00
BUILD_TYPE: "CI_NATIVE"
gitlab-ci, build: Move to Clang in Windows (native) This makes possible to use the Universal C library provided by Microsoft.
2024-03-05 01:47:14 +08:00
MSYSTEM: "CLANG64"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
CHERE_INVOKING: "yes"
tags:
- win32-ps
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
before_script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/2_build-gimp-msys2.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 1 day
paths:
- _install-x64
- _build-x64/build/windows/installer/
- _build-x64/meson-*/
cache:
paths:
- _ccache/
needs: ["deps-win-x64"]
packaging-win-x64:
rules:
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_WIN_INSTALLER != null'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
stage: packaging
variables:
gitlab-ci, build: Move to Clang in Windows (native) This makes possible to use the Universal C library provided by Microsoft.
2024-03-05 01:47:14 +08:00
MSYSTEM: "CLANG64"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
CHERE_INVOKING: "yes"
tags:
- win32-ps
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
before_script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/3_package-gimp-uni_base.sh"
- cd gimp-x64
- C:\msys64\usr\bin\bash -lc "bash -x ../build/windows/gitlab-ci/3_package-gimp-uni_sym.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 1 day
paths:
- gimp-x64
- done-dll.list
needs: ["gimp-win-x64"]
## WINDOWS x86 CI (native MSYS2) ##
deps-win-x86:
rules:
# 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'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
stage: dependencies
variables:
gitlab-ci, build/windows: Make Deps script compatible with Local-Native build The local builds now can use the same script of CI for sake of time. The compatibility layer is very simple and makes the script more used/tested, therefore more reliable. Also, remove some redundacy on the code for better maintenance.
2023-12-10 23:49:07 +08:00
BUILD_TYPE: "CI_NATIVE"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
MSYSTEM: "MINGW32"
CHERE_INVOKING: "yes"
tags:
- win32-ps
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
before_script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/1_build-deps-msys2.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 2 hours
paths:
- _install-x86
needs: []
gimp-win-x86:
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +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'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
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
variables:
gitlab-ci, build/windows: Make Build script compatible with Local-Native build The local builds now can use the same script of CI for sake of time. The compatibility layer is very simple and makes the script more used/tested, therefore more reliable.
2023-12-17 08:22:21 +08:00
BUILD_TYPE: "CI_NATIVE"
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
MSYSTEM: "MINGW32"
CHERE_INVOKING: "yes"
tags:
- win32-ps
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
before_script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/2_build-gimp-msys2.sh"
artifacts:
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
when: always
expire_in: 1 day
paths:
- _install-x86
- _build-x86/meson-*/
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
cache:
paths:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- _ccache/
needs: ["deps-win-x86"]
packaging-win-x86:
rules:
# On releases.
- if: '$CI_COMMIT_TAG != null'
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_WIN_INSTALLER != null'
# Merge requests with appropriate label.
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
stage: packaging
variables:
MSYSTEM: "MINGW32"
CHERE_INVOKING: "yes"
tags:
- win32-ps
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
before_script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\pacman --noconfirm -Syyuu
gitlab-ci, build/windows: Fix .patch and improve a little pacman upgrade * Fixes an ARM .patch that stop to working after !1171, causing job fail * Changes the logic of system upgrade (pacman -Syyuu) to be less redundant This also improves consistency with the Debian jobs
2024-01-16 01:55:35 +08:00
script:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- C:\msys64\usr\bin\bash -lc "bash -x ./build/windows/gitlab-ci/3_package-gimp-uni_base.sh"
- cd gimp-x86
- C:\msys64\usr\bin\bash -lc "bash -x ../build/windows/gitlab-ci/3_package-gimp-uni_sym.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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
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:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- gimp-x86
- done-dll.list
needs: ["gimp-win-x86"]
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
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +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 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
gitlab-ci, build/windows: Make Packaging scripts compatible with CI-Cross job The CI crossbuild job now use the same main script (and the same sub-scripts of linking and debug generation) of the native CI for packaging. These unified scripts greatly facilitates maintenance. The crossbuild deps script is now more consistent in relation to the native one. As this is polished, the cross one is now polished too. A crossroad gimp build script was created with a more clear code. Also, finally make the script for packaging only, removing build step stuff that shoudn't be here (glib-schemas generation) since this causes disparity with the Local native build; and adding some packaging decisions that shoudn't be in the installer scripts (eg. specific folders of ghostscript, glib; no share/themes), which also facillitates INNO (and future MSIX) maintenance.
2023-12-25 19:43:36 +08:00
-i _build-x64 -i _build-x86 -i _deps -i _install-x64 -i _install-x86 -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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
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
## Ready-to-distribute ##
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +08:00
dist-flatpak-weekly:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
extends: '.publish_nightly'
stage: distribution
rules:
# Custom builds though web GUI, API or schedules.
- if: '$GIMP_CI_FLATPAK != null'
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +08:00
needs: ["packaging-flatpak-x64"]
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
dependencies:
Partially revert "build/flatpak: Drop 'gimp_app_version' hardcoding" As suggested by Jehan, the manifest will be configured by meson. Of course, for CI compliance, this pushes the job to a further stage: 'packaging', which is what Flatpak is about, after all. The distribution job name has also been changed, because when Store job is merged, this will be the new nomenclature of the distribution jobs, which was not changed since !1171 by lack of time.
2024-01-19 20:54:18 +08:00
- 'packaging-flatpak-x64'
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
build/windows: Port Installer script to .ps1 This commit unites two scripts (.sh + .bat) in one .ps1. PS was choosed, since: 1) We don't need MSYS2 to distribute with Inno at first. Now, who wants to just distribute GIMP can do it easier natively without a separate environ. 2) PS is actually pretty solid and have a good number of cmdlets, unlike the ancient CMD, which barely supported more than 9 parameters in .bat files. Consequently, some redundant variable checks have been removed from the .ISS. Also, changes the name of the job and script for better consistency with the upcoming MS Store job.
2024-01-23 04:48:31 +08:00
dist-installer-weekly:
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, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- packaging-win-a64
- packaging-win-x64
- packaging-win-x86
Add a distribution job with Win 32-bit!
2021-05-09 22:03:53 +08:00
artifacts:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
Add a distribution job with Win 32-bit!
2021-05-09 22:03:53 +08:00
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
gitlab-ci: Expose job artifacts in UI Makes a bit easier to newcomers download the main artifacts in MRs. (This feature doesn't support variables or wildcards in paths)
2024-04-10 08:24:13 +08:00
expose_as: 'Windows exe'
Add a distribution job with Win 32-bit!
2021-05-09 22:03:53 +08:00
paths:
gitlab-ci: Expose job artifacts in UI Makes a bit easier to newcomers download the main artifacts in MRs. (This feature doesn't support variables or wildcards in paths)
2024-04-10 08:24:13 +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:
build/windows: Port Installer script to .ps1 This commit unites two scripts (.sh + .bat) in one .ps1. PS was choosed, since: 1) We don't need MSYS2 to distribute with Inno at first. Now, who wants to just distribute GIMP can do it easier natively without a separate environ. 2) PS is actually pretty solid and have a good number of cmdlets, unlike the ancient CMD, which barely supported more than 9 parameters in .bat files. Consequently, some redundant variable checks have been removed from the .ISS. Also, changes the name of the job and script for better consistency with the upcoming MS Store job.
2024-01-23 04:48:31 +08:00
- build/windows/gitlab-ci/4_dist-gimp-inno.ps1 | Out-File -FilePath installer.log
build, gitlab-ci: update dependencies. - With last commit, the Windows installer pipeline doesn't depend on "gimp-debian-x64" job anymore since a native Windows build is now able to run GIMP (or gimp-console) as a build-time tool as well. It makes the Windows installer pipeline (and full custom native builds) self-sufficient. - On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require "gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in order to generate some image data (such as the splash image, and probably soon logo or icons, etc.). See gimp-data@5a03c71. - Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of "image-debian-x64" for all Debian as well as the cross-compilation jobs. They are all based on the same Debian image (it was debian:bookworm for native Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork for all) and it's just a few more packages (cross-compilation C and C++ toolchains) for the cross-builds. Moreover now the cross-builds also need the native GIMP binary around, therefore native dependencies are needed as well. It makes sense to factorize all 3 images into 1. - Make sure we don't build bindings when cross-compiling since these won't work in this case.
2024-03-06 23:03:49 +08:00
needs: ["packaging-win-a64", "packaging-win-x64", "packaging-win-x86"]
Add a distribution job with Win 32-bit!
2021-05-09 22:03:53 +08:00
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
sources-debian:
gitlab-ci: distribute the meson-generated tarball as well. Maybe let's try to distribute the meson tarball next to the autotools tarball for our next dev release, and announce that packagers are invited to test the meson build from tarball and report back.
2022-08-02 02:13:32 +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'
stage: distribution
dependencies:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- gimp-debian-x64
gitlab-ci: distribute the meson-generated tarball as well. Maybe let's try to distribute the meson tarball next to the autotools tarball for our next dev release, and announce that packagers are invited to test the meson build from tarball and report back.
2022-08-02 02:13:32 +08:00
artifacts:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
gitlab-ci: distribute the meson-generated tarball as well. Maybe let's try to distribute the meson tarball next to the autotools tarball for our next dev release, and announce that packagers are invited to test the meson build from tarball and report back.
2022-08-02 02:13:32 +08:00
when: always
expire_in: 2 days
paths:
- gimp-*.tar.xz
- gimp-*.tar.xz.SHA256SUMS
- gimp-*.tar.xz.SHA512SUMS
script:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- mv _build${ARTIFACTS_SUFFIX}/meson-dist/gimp-*.tar.xz .
gitlab-ci: rename autotools/meson tarballs. If we want to encourage packagers to test the meson tarball (better to do this now with development releases than later on stable releases!), we should name it prominently. Therefore I will rename the autotools tarball as gimp-*-autotools.tar.bz2 whereas the meson tarball will be named gimp-*.tar.xz. Also renaming `sources` CI job to `sources-autotools`.
2022-08-09 00:15:33 +08:00
- FILENAME=`ls gimp-*.tar.xz` &&
gitlab-ci: distribute the meson-generated tarball as well. Maybe let's try to distribute the meson tarball next to the autotools tarball for our next dev release, and announce that packagers are invited to test the meson build from tarball and report back.
2022-08-02 02:13:32 +08:00
sha256sum gimp-*.tar.xz > ${FILENAME}.SHA256SUMS &&
sha512sum gimp-*.tar.xz > ${FILENAME}.SHA512SUMS
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
needs: ["gimp-debian-x64"]
gitlab-ci: distribute the meson-generated tarball as well. Maybe let's try to distribute the meson tarball next to the autotools tarball for our next dev release, and announce that packagers are invited to test the meson build from tarball and report back.
2022-08-02 02:13:32 +08:00
gitlab-ci: new job for dev docs. Instead of building it on the meson, build it on the autotools build. Also generate a new distribution job specifically for this.
2022-03-27 22:20:20 +08:00
dev-docs:
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'
stage: distribution
gitlab-ci: generate tarball for GIMP documentation.
2022-09-08 07:17:06 +08:00
image: $CI_REGISTRY_IMAGE:build-debian-latest
gitlab-ci: new job for dev docs. Instead of building it on the meson, build it on the autotools build. Also generate a new distribution job specifically for this.
2022-03-27 22:20:20 +08:00
dependencies:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
- deps-debian-x64
- gimp-debian-x64
gitlab-ci: new job for dev docs. Instead of building it on the meson, build it on the autotools build. Also generate a new distribution job specifically for this.
2022-03-27 22:20:20 +08:00
artifacts:
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
name: "${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
gitlab-ci: new job for dev docs. Instead of building it on the meson, build it on the autotools build. Also generate a new distribution job specifically for this.
2022-03-27 22:20:20 +08:00
when: always
expire_in: 2 days
paths:
gitlab-ci: generating tarballs for babl and GEGL API reference documentation.
2023-08-12 23:33:54 +08:00
- babl-api-docs-*.tar.xz
- babl-api-docs-*.tar.xz.SHA256SUMS
- babl-api-docs-*.tar.xz.SHA512SUMS
- gegl-api-docs-*.tar.xz
- gegl-api-docs-*.tar.xz.SHA256SUMS
- gegl-api-docs-*.tar.xz.SHA512SUMS
data, devel-docs, gitlab-ci: improve the docs tarball. - Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated HTML, and not an absolute path taken from build dir (otherwise this would break, for installed docs, but also for the tarball and the developer website!). - Also use either gimp-logo.png or gimp-devel-logo.png depending on whether we are on a stable or unstable branch. - Install these in images/ inside the GIMP docs folder, which corresponds to the relative path given to GIMP_LOGO_PATH. - The installed root dir will be $datadir/doc/gimp-2.99/, e.g. /usr/share/doc/gimp-2.99/ - Inside this folder, the library references will be in libgimp-3.0/ and libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that the root dir uses the application version (2.99) whereas the library folder use the API versions. These are different in development phase. - Archive the gi-docgen installed files, not taken from the build dir, to avoid packaging temp files, such as the .toml files. Note that `g-ir-docs` files are still taken from the build dir, as we don't install them yet. - Finally package all this in a directory before archiving in a tar.xz, named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside gimp-api-docs-2.99.13.tar.xz).
2022-09-09 22:37:40 +08:00
- gimp-api-docs-*.tar.xz
- gimp-api-docs-*.tar.xz.SHA256SUMS
- gimp-api-docs-*.tar.xz.SHA512SUMS
gitlab-ci: new job for dev docs. Instead of building it on the meson, build it on the autotools build. Also generate a new distribution job specifically for this.
2022-03-27 22:20:20 +08:00
script:
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- BABL_VER=$(grep BABL_VERSION _babl/_build${ARTIFACTS_SUFFIX}/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/') &&
BABL_API_VER=$(grep BABL_API_VERSION _babl/_build${ARTIFACTS_SUFFIX}/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/') &&
gitlab-ci: generating tarballs for babl and GEGL API reference documentation.
2023-08-12 23:33:54 +08:00
DIR_NAME=babl-api-docs-$BABL_VER &&
mkdir $DIR_NAME &&
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
mv "${GIMP_PREFIX}/share/doc/babl-$BABL_API_VER" $DIR_NAME/ &&
gitlab-ci: generating tarballs for babl and GEGL API reference documentation.
2023-08-12 23:33:54 +08:00
TAR_NAME="$DIR_NAME.tar.xz" &&
data, plug-ins: logo images moved to gimp-data repository. Now the development and stable logos will be generated from gimp-data. In other changes, the gi-docgen logo is installed as a symlink using install_symlink() which exists since meson 0.61.0 so I bumped our meson dependency (in practice we were already using this function anyway and Debian bookworm has meson 1.0.1 so it's all good). Finally I don't install a wilber.png anymore, which was only used by script-fu testing, and which was the same as gimp-logo.png (except 256x256 instead of 128x128). Unless mistaken, all script-fu tests loading this image still work with the change. The only one where I needed further change was buffer.scm (which was checking the dimensions). See gimp-data@9aa6e35.
2024-03-10 02:04:57 +08:00
tar --dereference -cJf ${TAR_NAME} $DIR_NAME &&
gitlab-ci: generating tarballs for babl and GEGL API reference documentation.
2023-08-12 23:33:54 +08:00
sha256sum $TAR_NAME > ${TAR_NAME}.SHA256SUMS &&
sha512sum $TAR_NAME > ${TAR_NAME}.SHA512SUMS
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- GEGL_MAJ_VER=$(grep GEGL_MAJOR_VERSION _gegl/_build${ARTIFACTS_SUFFIX}/config.h |head -1 |sed 's/^[^0-9]*\([0-9]*\).*$/\1/') &&
GEGL_MIN_VER=$(grep GEGL_MINOR_VERSION _gegl/_build${ARTIFACTS_SUFFIX}/config.h |head -1 |sed 's/^[^0-9]*\([0-9]*\).*$/\1/') &&
GEGL_MIC_VER=$(grep GEGL_MICRO_VERSION _gegl/_build${ARTIFACTS_SUFFIX}/config.h |head -1 |sed 's/^[^0-9]*\([0-9]*\).*$/\1/') &&
gitlab-ci: generating tarballs for babl and GEGL API reference documentation.
2023-08-12 23:33:54 +08:00
GEGL_VER="$GEGL_MAJ_VER.$GEGL_MIN_VER.$GEGL_MIC_VER" &&
GEGL_API_VER="$GEGL_MAJ_VER.$GEGL_MIN_VER" &&
DIR_NAME=gegl-api-docs-$GEGL_VER &&
mkdir $DIR_NAME &&
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
mv "${GIMP_PREFIX}/share/doc/gegl-$GEGL_API_VER" $DIR_NAME/ &&
gitlab-ci: generating tarballs for babl and GEGL API reference documentation.
2023-08-12 23:33:54 +08:00
TAR_NAME="$DIR_NAME.tar.xz" &&
data, plug-ins: logo images moved to gimp-data repository. Now the development and stable logos will be generated from gimp-data. In other changes, the gi-docgen logo is installed as a symlink using install_symlink() which exists since meson 0.61.0 so I bumped our meson dependency (in practice we were already using this function anyway and Debian bookworm has meson 1.0.1 so it's all good). Finally I don't install a wilber.png anymore, which was only used by script-fu testing, and which was the same as gimp-logo.png (except 256x256 instead of 128x128). Unless mistaken, all script-fu tests loading this image still work with the change. The only one where I needed further change was buffer.scm (which was checking the dimensions). See gimp-data@9aa6e35.
2024-03-10 02:04:57 +08:00
tar --dereference -cJf ${TAR_NAME} $DIR_NAME &&
gitlab-ci: generating tarballs for babl and GEGL API reference documentation.
2023-08-12 23:33:54 +08:00
sha256sum $TAR_NAME > ${TAR_NAME}.SHA256SUMS &&
sha512sum $TAR_NAME > ${TAR_NAME}.SHA512SUMS
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
- GIMP_VER=$(grep GIMP_VERSION _build${ARTIFACTS_SUFFIX}/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/') &&
data, devel-docs, gitlab-ci: improve the docs tarball. - Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated HTML, and not an absolute path taken from build dir (otherwise this would break, for installed docs, but also for the tarball and the developer website!). - Also use either gimp-logo.png or gimp-devel-logo.png depending on whether we are on a stable or unstable branch. - Install these in images/ inside the GIMP docs folder, which corresponds to the relative path given to GIMP_LOGO_PATH. - The installed root dir will be $datadir/doc/gimp-2.99/, e.g. /usr/share/doc/gimp-2.99/ - Inside this folder, the library references will be in libgimp-3.0/ and libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that the root dir uses the application version (2.99) whereas the library folder use the API versions. These are different in development phase. - Archive the gi-docgen installed files, not taken from the build dir, to avoid packaging temp files, such as the .toml files. Note that `g-ir-docs` files are still taken from the build dir, as we don't install them yet. - Finally package all this in a directory before archiving in a tar.xz, named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside gimp-api-docs-2.99.13.tar.xz).
2022-09-09 22:37:40 +08:00
APP_VER=$(echo $GIMP_VER | sed 's/\([0-9]\+\.[0-9]\+\)\..*/\1/') &&
DIR_NAME=gimp-api-docs-$GIMP_VER &&
mkdir $DIR_NAME &&
Partially reverts 9d279a60 and 4f965557 These commits introduced sensible drawbacks in our CI file organization. Some of them I already commented in the MR but was "ignored" back then probably due to the complexity of the MR. So, the let's revert: - Unecessary repetition of libomp installation (4 times, now 1) - Unecessary repetition of submodule initialization (6 times, now 4) - Creation of new variables in the hope of more clarity. But, they aren't consistent with the gimp-web-devel instructions nor with other systems variables. This is terrible to undestand. Please, let's not reinvent the wheel since this is a bad example to packagers, since they tends to isolation and overly-engineering. Also, made some little adjustments that I should have done in previous MR. --- This MR was splitted. Even more simplification will be done in the future.
2024-03-28 19:41:26 +08:00
mv "${GIMP_PREFIX}/share/doc/gimp-$APP_VER" $DIR_NAME/reference &&
mv _build${ARTIFACTS_SUFFIX}/devel-docs/g-ir-docs $DIR_NAME/ &&
data, devel-docs, gitlab-ci: improve the docs tarball. - Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated HTML, and not an absolute path taken from build dir (otherwise this would break, for installed docs, but also for the tarball and the developer website!). - Also use either gimp-logo.png or gimp-devel-logo.png depending on whether we are on a stable or unstable branch. - Install these in images/ inside the GIMP docs folder, which corresponds to the relative path given to GIMP_LOGO_PATH. - The installed root dir will be $datadir/doc/gimp-2.99/, e.g. /usr/share/doc/gimp-2.99/ - Inside this folder, the library references will be in libgimp-3.0/ and libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that the root dir uses the application version (2.99) whereas the library folder use the API versions. These are different in development phase. - Archive the gi-docgen installed files, not taken from the build dir, to avoid packaging temp files, such as the .toml files. Note that `g-ir-docs` files are still taken from the build dir, as we don't install them yet. - Finally package all this in a directory before archiving in a tar.xz, named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside gimp-api-docs-2.99.13.tar.xz).
2022-09-09 22:37:40 +08:00
TAR_NAME="$DIR_NAME.tar.xz" &&
data, plug-ins: logo images moved to gimp-data repository. Now the development and stable logos will be generated from gimp-data. In other changes, the gi-docgen logo is installed as a symlink using install_symlink() which exists since meson 0.61.0 so I bumped our meson dependency (in practice we were already using this function anyway and Debian bookworm has meson 1.0.1 so it's all good). Finally I don't install a wilber.png anymore, which was only used by script-fu testing, and which was the same as gimp-logo.png (except 256x256 instead of 128x128). Unless mistaken, all script-fu tests loading this image still work with the change. The only one where I needed further change was buffer.scm (which was checking the dimensions). See gimp-data@9aa6e35.
2024-03-10 02:04:57 +08:00
tar --dereference -cJf ${TAR_NAME} $DIR_NAME &&
data, devel-docs, gitlab-ci: improve the docs tarball. - Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated HTML, and not an absolute path taken from build dir (otherwise this would break, for installed docs, but also for the tarball and the developer website!). - Also use either gimp-logo.png or gimp-devel-logo.png depending on whether we are on a stable or unstable branch. - Install these in images/ inside the GIMP docs folder, which corresponds to the relative path given to GIMP_LOGO_PATH. - The installed root dir will be $datadir/doc/gimp-2.99/, e.g. /usr/share/doc/gimp-2.99/ - Inside this folder, the library references will be in libgimp-3.0/ and libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that the root dir uses the application version (2.99) whereas the library folder use the API versions. These are different in development phase. - Archive the gi-docgen installed files, not taken from the build dir, to avoid packaging temp files, such as the .toml files. Note that `g-ir-docs` files are still taken from the build dir, as we don't install them yet. - Finally package all this in a directory before archiving in a tar.xz, named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside gimp-api-docs-2.99.13.tar.xz).
2022-09-09 22:37:40 +08:00
sha256sum $TAR_NAME > ${TAR_NAME}.SHA256SUMS &&
sha512sum $TAR_NAME > ${TAR_NAME}.SHA512SUMS
gitlab-ci, build/windows: Unify CI jobs wording Debian changes: - Since autotools has gone, we don't need to specify 'meson' in the debian job and others. - The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and the meson sintax of Debian jobs was also updated. Windows changes: - Then, clarify that the win64-nightly and win32-nightly jobs are, in fact, in the 'packaging' step, since we don't really "distribute" GIMP in .zip and the commands are almost the same of the packaging .SH script, without scripted optimizations for Inno Installer (or future .MSIX), crucial for distribution. - We don't need to specify "native" sufix in any build since they are the rule and cross builds are the exception. General changes: - The job names was changed to be more consistent and in accordance with the folders present in the artifacts. - The 'nightly' sufix was removed from the Inno Windows Installer job and others, since this doesn't reflect the real build frequency. - The scripts filenames are altered to stay "in order". This is not essential but ultra convenient since it is easy to view and search. (The -uni suffix is explained in a further commit) - All artifacts names now have the commit to avoid apparently duplicate files when downloading same step artifacts from different projects. - Finally, rearrange the order of jobs rationally: first the OSes and archs (from the most free and modern to the most closed and legacy), then the stages (from 'prepare' to 'analysis'), ending with the frequency of jobs (from the most frequent, called at each push, to the least/weekly). Overall, this changes, although difficult to review at the first sight, will avoid in the future quite "dumb" issues like: GNOME/gimp#10195
2023-12-08 04:12:44 +08:00
needs: ["deps-debian-x64", "gimp-debian-x64"]
Revert "gitlab-ci: removing win*-nightly jobs." This reverts commit c11dc691373d9c049d216c74028727afcbb65576.
2022-10-27 02:33:02 +08:00