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

826 lines
26 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, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
# - Linux build (base & fast)
# - Win crossbuild (base & fast)
gitlab-ci: More little fixes regarding 'file-plug-in-tests'
2024-04-30 17:50:58 +08:00
# - Execution tests (dynamic 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
# Scheduled CI ($CI_PIPELINE_SOURCE == "schedule") will run regularly:
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
# - Linux GCC build (rare usefulness)
# - Linux build without vector icons (rare usefulness)
# - Linux Flatpak build (base but slow)
gitlab-ci, build/windows: Add MS Store job to CI The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
2023-11-18 00:08:07 +08:00
# - Win builds: Inno Windows installer and .msixbundle (base but slow)
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: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
# - Source tarball (base & fast)
# - Developer documentation (base & fast)
gitlab-ci, build/windows: Add MS Store job to CI The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
2023-11-18 00:08:07 +08:00
# - Win builds: Inno Windows installer and .msixupload (base but slow)
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: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
# - GIMP_CI_MESON_CLANG: trigger the Debian Clang build with AppImage artifact.
# - GIMP_CI_MESON_GCC: trigger the Debian GCC build with AppImage artifact.
# - GIMP_CI_RASTER_ICONS: trigger the Debian Clang build with AppImage artifact without vector icons.
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_CROSSROAD_WIN64: trigger the crossroad build for Win 64-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.
gitlab-ci: Move 'analysis' stage to a more "mainstream" position I suppose the intention of having this stage at the end was to make clear: no job depends on it. However, this place is not common or ideal but one of two: 1) before building, which is more linear; or 2) after building (the choosen) even if this isn't dynamic analysis (tests), since they are both related and some compilers and build systems do static analysis. Anyway, not after dist. The new place is a bit more clear to devs used at "build, test, deploy" praxis and maybe will be now better noticed by the existing devs before distributing. It's not perfect, since I explained above that there are two places/approaches. Obviously, the stage continues to be OPTIONAL to pass, nothing was changed. --- Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:" and made the artifacts paths of clang-format and cppcheck more consistent.
2024-04-20 09:28:16 +08:00
# - GIMP_CI_CPPCHECK: trigger cppcheck static analysis.
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
# - GIMP_CI_SOURCES: trigger the Debian Clang build and the source tarball job.
gitlab-ci: Drop 'packaging' stage This stage was introduced in 076e4d68 and it fulfilled well its purpose. But the side effects were: more (sometimes slow) uploading and downloading of packages and artifacts. Even if we have caching, this is far from ideal. Now, the so-called "packaging" jobs were moved inside in the "build" jobs. The advantages are: just one pacman install (ideally cached from deps job); direct packaging without waiting for upload/download; and less confusion, since "packaging" naming was implying that the .zips are somewhat official, which isn't totally true, and sometimes overlaps the dist/deploy concept. --- Also, the flatpak job now uses config.h instead of triggering a GIMP build. In other words, I'm reverting part of my work in some old commits.
2024-04-16 08:12:39 +08:00
# - GIMP_CI_FLATPAK: trigger the flatpak build and 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
# - GIMP_CI_WIN_INSTALLER: trigger all native MSYS2 builds then creates Inno Windows installer.
gitlab-ci, build/windows: Add MS Store job to CI The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
2023-11-18 00:08:07 +08:00
# - GIMP_CI_MS_STORE: trigger arm64 and x64 native MSYS2 builds then creates a .msixbundle.
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: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
# Make pipelines auto cancelable when explicity set (e.g. in 'rules')
# GitLab is quite sensitive about the "if" order so we organize them
# in a way to avoid as much as possible hardcoding and leaks in "rules"
gitlab-ci: Make the CI a little more smart Now, the CI will auto cancel jobs after a new commit is pushed and retry when the runners fails. The first case is frequent, the last is rare but happened.
2024-04-16 18:50:35 +08:00
workflow:
auto_cancel:
on_new_commit: interruptible
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
## On merge requests.
.pipeline_merge: &CI_MERGE
if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
gitlab-ci: Make the CI a little more smart Now, the CI will auto cancel jobs after a new commit is pushed and retry when the runners fails. The first case is frequent, the last is rare but happened.
2024-04-16 18:50:35 +08:00
interruptible: true
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
variables: {}
## Merge requests with appropriate label.
#'interruptible: true' needs to be hardcoded
## On commits except tags.
.pipeline_commit: &CI_COMMIT
if: '$CI_PIPELINE_SOURCE == "push" && $CI_OPEN_MERGE_REQUESTS == null && $CI_COMMIT_TAG == null'
interruptible: true
variables: {}
## On releases.
.pipeline_release: &CI_RELEASE
if: '$CI_COMMIT_TAG != null'
interruptible: false
variables: {}
.default:
## Custom builds though web GUI, API or schedules.
interruptible: false
gitlab-ci: Improve the order of beginning of .yml Pure cosmetical change to more linear reading. This makes related Keywords more closer to each other.
2024-05-01 00:07:12 +08:00
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
# Common jobs behavior
gitlab-ci: Make the CI a little more smart Now, the CI will auto cancel jobs after a new commit is pushed and retry when the runners fails. The first case is frequent, the last is rare but happened.
2024-04-16 18:50:35 +08:00
retry:
max: 1
when:
- 'runner_system_failure'
- 'scheduler_failure'
gitlab-ci: Move 'image:' from deprecated global to .default
2024-04-14 18:48:25 +08:00
# Default Docker image (unless otherwise defined)
image: debian:bookworm
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
# Caching support
variables:
CCACHE_BASEDIR: "$CI_PROJECT_DIR"
CCACHE_DIR: "$CI_PROJECT_DIR/_ccache"
CC: "ccache clang"
CXX: "ccache clang++"
gitlab-ci: Use LLD linker in Debian and Flatpak jobs Following 55427487 and 85ed2847 It is a bit unusual to use 'clang' + 'GNU ld' combo. Also, lld is advertised to be way faster.
2024-06-01 00:09:33 +08:00
CC_LD: lld
CXX_LD: lld
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
cache:
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
key: ${CI_JOB_NAME}${VARIANT}
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
paths:
- _ccache/
gitlab-ci: Make use of 'before_script' less unorthodox Since !1171 the 'before_script' was being used by me for organization, but this is at least unexpected to "mainstream" .yml pratice and can be wrong. For example, the universal variables can't be properly used this way. So, let's use 'before_script' only for the (official) purpose: save code.
2024-04-14 03:22:05 +08:00
# Universal variables (works in all POSIX OSes and archs)
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
before_script:
- export PATH="$GIMP_PREFIX/bin:$PATH"
build/windows: Fixes and cleanup to native scripts Previous changes broken local building courtesy and probably DirectInput too. Noticed that the universal variables can not work in some contexts, fixed. Also, done some little cleanups.
2024-05-19 18:55:17 +08:00
- gcc -print-multi-os-directory 2>/dev/null | grep ./ && LIB_DIR=$(gcc -print-multi-os-directory | sed 's/\.\.\///g') || LIB_DIR="lib"
gitlab-ci: Silence universal variables They were generating a distracting output in CLANG* shells, as noted by @lillolollo in a comment from MR: Infrastructure/gimp-web-devel!65 In the process, make AppImage and Windows (native) scripts use these variables, without hardcoding the same variables from .yml anymore.
2024-04-21 22:42:18 +08:00
- gcc -print-multiarch 2>/dev/null | grep . && LIB_SUBDIR=$(echo $(gcc -print-multiarch)'/')
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +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}"
# Common artifacts behavior
artifacts:
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
name: "${CI_JOB_NAME}${VARIANT}-${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
when: always
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
variables:
gitlab-ci: Clarify some CI-wide variables
2024-04-21 07:17:57 +08:00
# Common cloning procedure
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"
gitlab-ci, build/windows: Organize 'git' variables
2024-04-14 06:06:57 +08:00
GIT_SUBMODULE_STRATEGY: recursive
gitlab-ci: Clarify some CI-wide variables
2024-04-21 07:17:57 +08:00
# CI-wide Debian variables
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
GIMP_PREFIX: "${CI_PROJECT_DIR}/_install"
gitlab-ci, meson: Enable colored Clang output This makes easier to spot warnings.
2024-06-14 09:25:29 +08:00
# Enable colorful output when supported (e.g. ninja, cppcheck)
CLICOLOR_FORCE: "1"
build: adding a .gitlab-ci.yml file for automated GitLab pipeline builds
2019-07-29 07:11:44 +08:00
gitlab-ci: Move 'image:' from deprecated global to .default
2024-04-14 18:48:25 +08:00
gitlab-ci: Improve the order of beginning of .yml Pure cosmetical change to more linear reading. This makes related Keywords more closer to each other.
2024-05-01 00:07:12 +08:00
stages:
- prepare
- dependencies
- gimp
- analysis
- distribution
gitlab-ci: Move 'image:' from deprecated global to .default
2024-04-14 18:48:25 +08:00
## prepare build-oriented Docker images ##
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
.debian:
gitlab-ci: add Win 32-bit and Linux Clang builds to schedules. These are interesting and may find very specific bugs from time to time, but the usefulness is rare enough not to warrant to run at each commits. This is just a waste of resources. For scheduling finesse (in case we want to separate these in separate scheduling), also rely on the existence of variables during scheduling. Finally make sure that the non-scheduled builds are not run in schedule pipelines (they are already run far enough).
2021-05-06 21:38:23 +08:00
rules:
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
- <<: *CI_MERGE
- <<: *CI_COMMIT
- if: '$GIMP_CI_MESON_CLANG != null'
variables: {}
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: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
variables:
CC: "ccache cc"
CXX: "ccache c++"
gitlab-ci: Use LLD linker in Debian and Flatpak jobs Following 55427487 and 85ed2847 It is a bit unusual to use 'clang' + 'GNU ld' combo. Also, lld is advertised to be way faster.
2024-06-01 00:09:33 +08:00
CC_LD: bfd
CXX_LD: bfd
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
VARIANT: "-gcc"
gitlab-ci: add a new GIMP_CI_RASTER_ICONS to test raster icon build. Since this is probably much less tested than the default vector icon case, any bug there might go unseen for some time. So let's add a new pipeline to check this. I make so this pipeline is not actually run on every commit (i.e. manually only), then I'll just add a scheduled pipeline to check the non-vector icon case at regular intervals. This pipeline also test the icon-list.mk files are not outdated.
2022-01-27 23:32:02 +08:00
- if: '$GIMP_CI_RASTER_ICONS != null'
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
variables:
MESON_OPTIONS: "-Dvector-icons=false"
VARIANT: "-raster"
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'
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'
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
- <<: *CI_RELEASE
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
image-debian-x64:
rules:
- !reference [.debian, rules]
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
stage: prepare
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
variables:
GIT_STRATEGY: none
cache: {}
CI: use custom docker images for dependencies and GIMP builds
2020-05-30 06:41:22 +08:00
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
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
ccache
clang
gitlab-ci: Use LLD linker in Debian and Flatpak jobs Following 55427487 and 85ed2847 It is a bit unusual to use 'clang' + 'GNU ld' combo. Also, lld is advertised to be way faster.
2024-06-01 00:09:33 +08:00
lld
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
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
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
gjs
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
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
build: openjpeg dependency was missing Both in our Debian and Windows deps the openjpeg dependency was missing, so let's add it back.
2024-04-22 00:40:41 +08:00
libopenjp2-7-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
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: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
deps-debian-x64:
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
extends: .default
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
rules:
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
- !reference [.debian, rules]
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
needs: ["image-debian-x64"]
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: Make use of 'before_script' less unorthodox Since !1171 the 'before_script' was being used by me for organization, but this is at least unexpected to "mainstream" .yml pratice and can be wrong. For example, the universal variables can't be properly used this way. So, let's use 'before_script' only for the (official) purpose: save code.
2024-04-14 03:22:05 +08:00
script:
# Clone babl and GEGL
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
build/windows: Make sources downloading more neutral This makes crossroad and msys2 scripts clone without the "_" prefix, which will improve quality of life of most contributors that just clone them. Just for consistency, also remove the "_" prefix from other pices of code.
2024-07-28 18:42:02 +08:00
- git clone $babl_branch --depth=${GIT_DEPTH} https://gitlab.gnome.org/GNOME/babl.git
- git clone $gegl_branch --depth=${GIT_DEPTH} https://gitlab.gnome.org/GNOME/gegl.git
gitlab-ci: Make use of 'before_script' less unorthodox Since !1171 the 'before_script' was being used by me for organization, but this is at least unexpected to "mainstream" .yml pratice and can be wrong. For example, the universal variables can't be properly used this way. So, let's use 'before_script' only for the (official) purpose: save code.
2024-04-14 03:22:05 +08:00
# Build babl and GEGL
build/windows: Make sources downloading more neutral This makes crossroad and msys2 scripts clone without the "_" prefix, which will improve quality of life of most contributors that just clone them. Just for consistency, also remove the "_" prefix from other pices of code.
2024-07-28 18:42:02 +08:00
- mkdir babl/_build && cd babl/_build
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
- meson setup .. -Dprefix="${GIMP_PREFIX}"
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
- ninja
- ninja install
- ccache --show-stats
build/windows: Make sources downloading more neutral This makes crossroad and msys2 scripts clone without the "_" prefix, which will improve quality of life of most contributors that just clone them. Just for consistency, also remove the "_" prefix from other pices of code.
2024-07-28 18:42:02 +08:00
- mkdir ../../gegl/_build && cd ../../gegl/_build
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
- meson setup .. -Dprefix="${GIMP_PREFIX}"
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
- ninja
- ninja install
- ccache --show-stats
artifacts:
paths:
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- _install/
build/windows: Make sources downloading more neutral This makes crossroad and msys2 scripts clone without the "_" prefix, which will improve quality of life of most contributors that just clone them. Just for consistency, also remove the "_" prefix from other pices of code.
2024-07-28 18:42:02 +08:00
- babl/_build/meson-logs/meson-log.txt
- gegl/_build/meson-logs/meson-log.txt
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
expire_in: 2 hours
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
gimp-debian-x64:
extends: .default
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
rules:
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
- !reference [.debian, rules]
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
needs: ["deps-debian-x64"]
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
Update gitlab-ci
2019-08-09 22:18:43 +08:00
script:
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
# Check building
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- mkdir -p _build && cd _build
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
- 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
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
-Drelocatable-bundle=no
$MESON_OPTIONS
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
- ninja
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
# Check execution
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
- ninja test
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
# Check source
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
- if [ $(git diff |wc -l) -ne 0 ]; then
git diff;
exit 1;
fi
- if [ "$VARIANT" != "-gcc" ] && [ "$VARIANT" != "-raster" ] && [ "$CI_PIPELINE_SOURCE" != "merge_request_event" ]; then
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
ninja dist;
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
fi
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
# Make sure that GIMP is testable locally on Debian
# We apply these ugly patches since #6798 isn't fixed yet
# and appstream-cli get confused with our exotic naming and fails
- cd ..
- git apply -v build/linux/appimage/patches/0001-desktop-po-Use-reverse-DNS-naming.patch
build, tools, gimp-data: removing gimp_exe_config_dir from the root meson.build. Creating a temporary config directory for the in-build GIMP (run as a tool or for unit-testing) is not done as a build target anymore, but in the in-build-gimp.sh script as a unique temp directory, then cleaned out on exit. This has a few advantages: - It is properly cleaned out once the build ends (instead of leaving a full config dir as trash inside the build dir). - It is not reused from one build to another (with risk of carrying bugs and issues over). - Every use of the in-build GIMP will have its own config directory, and in particular when they are called in parallel. As a side update, make sure that all `gimp_exe` runs depend on `gimp_exe_depends`.
2024-04-22 04:37:45 +08:00
- cd gimp-data
- git apply -v ../build/linux/appimage/patches/0001-images-logo-Use-reverse-DNS-naming.patch
- cd ..
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- meson configure _build -Drelocatable-bundle=yes -Dvector-icons=true
- cd _build
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
- ninja
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
- ninja install
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
- ccache --show-stats
- cd ..
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- bash build/linux/appimage/2_bundle-gimp-appimage.sh
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: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
expose_as: 'Linux appimage'
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
paths:
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
- build/linux/appimage/_Output/
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- _install/
- _build/meson-logs/meson-log.txt
- _build/meson-dist/
- _build/config.h
- _build/devel-docs/
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
reports:
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
junit: "_build/meson-logs/testlog.junit.xml"
gitlab-ci, build: Unify Debian jobs and add AppImage artifact AppImage is pretty fast to make, like the win crossbuild; and portable, being very appropriate to do quick tests on Linux when pushing to git. The overall organization of Debian jobs was changed to take advantage of this and make things less complicated (but less clear at first sight). I reinforce that this was the most efficent way to make the AppImage.
2024-03-28 02:20:25 +08:00
expire_in: 2 days
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
Issue #11455: Split flatpak jobs - Dependencies not present in GNOME runtime are now built in deps stage This makes easier to follow the progress of the overall pipeline and to know how much time was spent on each stage (like crossbuilds, the artifact size is brutal but only lasts 2 hours) - babl and GEGL build now have output in GitLab runner, unlike others deps This makes clearer to spot if something goes wrong in these crucial deps - GIMP is still built in its stage but now alone, like Debian and Windows This makes possible to retrigger only this job when runner errors occours, without needing to start monolithically the deps+gimp build from scratch Also: - babl, GEGL and GIMP now have meson-log.txt artifact like other builds - dist job now have all commands self-contained on its script (needs to be merged to be tested according to my tests)
2024-07-07 04:52:17 +08:00
.flatpak-x64:
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
extends: .default
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
rules:
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Flatpak package.*/'
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
interruptible: true
- if: '$GIMP_CI_FLATPAK != null'
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
tags:
- flatpak
image: 'quay.io/gnome_infrastructure/gnome-runtime-images:gnome-master'
Issue #11455: Split flatpak jobs - Dependencies not present in GNOME runtime are now built in deps stage This makes easier to follow the progress of the overall pipeline and to know how much time was spent on each stage (like crossbuilds, the artifact size is brutal but only lasts 2 hours) - babl and GEGL build now have output in GitLab runner, unlike others deps This makes clearer to spot if something goes wrong in these crucial deps - GIMP is still built in its stage but now alone, like Debian and Windows This makes possible to retrigger only this job when runner errors occours, without needing to start monolithically the deps+gimp build from scratch Also: - babl, GEGL and GIMP now have meson-log.txt artifact like other builds - dist job now have all commands self-contained on its script (needs to be merged to be tested according to my tests)
2024-07-07 04:52:17 +08:00
deps-flatpak-x64:
extends: .flatpak-x64
rules:
- !reference [.flatpak-x64, rules]
needs: []
stage: dependencies
# FIXME: GitLab CI caching does NOT work with flatpak
gitlab-ci, build/linux: Move Flatpak CI code to scripts that works This will make easier to debug problems locally if needed and have the potential to reduce the first barrier for Linux newbies.
2024-05-21 22:53:34 +08:00
# See: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1502
cache: []
# key: ${CI_JOB_NAME}-pkg
# paths:
Issue #11455: Split flatpak jobs - Dependencies not present in GNOME runtime are now built in deps stage This makes easier to follow the progress of the overall pipeline and to know how much time was spent on each stage (like crossbuilds, the artifact size is brutal but only lasts 2 hours) - babl and GEGL build now have output in GitLab runner, unlike others deps This makes clearer to spot if something goes wrong in these crucial deps - GIMP is still built in its stage but now alone, like Debian and Windows This makes possible to retrigger only this job when runner errors occours, without needing to start monolithically the deps+gimp build from scratch Also: - babl, GEGL and GIMP now have meson-log.txt artifact like other builds - dist job now have all commands self-contained on its script (needs to be merged to be tested according to my tests)
2024-07-07 04:52:17 +08:00
# .flatpak-builder/
# key: $CI_JOB_NAME
# paths:
# _ccache/
gitlab-ci: Make use of 'before_script' less unorthodox Since !1171 the 'before_script' was being used by me for organization, but this is at least unexpected to "mainstream" .yml pratice and can be wrong. For example, the universal variables can't be properly used this way. So, let's use 'before_script' only for the (official) purpose: save code.
2024-04-14 03:22:05 +08:00
script:
gitlab-ci, build/linux: Move Flatpak CI code to scripts that works This will make easier to debug problems locally if needed and have the potential to reduce the first barrier for Linux newbies.
2024-05-21 22:53:34 +08:00
- bash build/linux/flatpak/1_build-deps-flatpak.sh
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
artifacts:
paths:
Issue #11455: Split flatpak jobs - Dependencies not present in GNOME runtime are now built in deps stage This makes easier to follow the progress of the overall pipeline and to know how much time was spent on each stage (like crossbuilds, the artifact size is brutal but only lasts 2 hours) - babl and GEGL build now have output in GitLab runner, unlike others deps This makes clearer to spot if something goes wrong in these crucial deps - GIMP is still built in its stage but now alone, like Debian and Windows This makes possible to retrigger only this job when runner errors occours, without needing to start monolithically the deps+gimp build from scratch Also: - babl, GEGL and GIMP now have meson-log.txt artifact like other builds - dist job now have all commands self-contained on its script (needs to be merged to be tested according to my tests)
2024-07-07 04:52:17 +08:00
- .flatpak-builder.tar
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
- flatpak-builder.log
Issue #11455: Split flatpak jobs - Dependencies not present in GNOME runtime are now built in deps stage This makes easier to follow the progress of the overall pipeline and to know how much time was spent on each stage (like crossbuilds, the artifact size is brutal but only lasts 2 hours) - babl and GEGL build now have output in GitLab runner, unlike others deps This makes clearer to spot if something goes wrong in these crucial deps - GIMP is still built in its stage but now alone, like Debian and Windows This makes possible to retrigger only this job when runner errors occours, without needing to start monolithically the deps+gimp build from scratch Also: - babl, GEGL and GIMP now have meson-log.txt artifact like other builds - dist job now have all commands self-contained on its script (needs to be merged to be tested according to my tests)
2024-07-07 04:52:17 +08:00
- babl-meson-log.tar
- gegl-meson-log.tar
expire_in: 2 hours
gimp-flatpak-x64:
extends: .flatpak-x64
rules:
- !reference [.flatpak-x64, rules]
needs: ["deps-flatpak-x64"]
stage: gimp
# FIXME: GitLab CI caching does NOT work with flatpak
# See: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1502
cache: []
# key: $CI_JOB_NAME
# paths:
# _ccache/
script:
- bash build/linux/flatpak/2_build-gimp-flatpak.sh
artifacts:
paths:
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
- repo.tar
Issue #11455: Split flatpak jobs - Dependencies not present in GNOME runtime are now built in deps stage This makes easier to follow the progress of the overall pipeline and to know how much time was spent on each stage (like crossbuilds, the artifact size is brutal but only lasts 2 hours) - babl and GEGL build now have output in GitLab runner, unlike others deps This makes clearer to spot if something goes wrong in these crucial deps - GIMP is still built in its stage but now alone, like Debian and Windows This makes possible to retrigger only this job when runner errors occours, without needing to start monolithically the deps+gimp build from scratch Also: - babl, GEGL and GIMP now have meson-log.txt artifact like other builds - dist job now have all commands self-contained on its script (needs to be merged to be tested according to my tests)
2024-07-07 04:52:17 +08:00
- gimp-meson-log.tar
gitlab-ci: Drop 'packaging' stage This stage was introduced in 076e4d68 and it fulfilled well its purpose. But the side effects were: more (sometimes slow) uploading and downloading of packages and artifacts. Even if we have caching, this is far from ideal. Now, the so-called "packaging" jobs were moved inside in the "build" jobs. The advantages are: just one pacman install (ideally cached from deps job); direct packaging without waiting for upload/download; and less confusion, since "packaging" naming was implying that the .zips are somewhat official, which isn't totally true, and sometimes overlaps the dist/deploy concept. --- Also, the flatpak job now uses config.h instead of triggering a GIMP build. In other words, I'm reverting part of my work in some old commits.
2024-04-16 08:12:39 +08:00
expire_in: 2 days
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: Reduce redundancy on Windows cross jobs (take 1) Our crossroad jobs are too "sensible" and prone to broke so let's go gradually.
2024-04-13 07:33:27 +08:00
.win-cross:
extends: .default
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
rules:
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
- <<: *CI_MERGE
- <<: *CI_COMMIT
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
- if: '$GIMP_CI_CROSSROAD_WIN64 != null'
image: $CI_REGISTRY_IMAGE:build-debian-latest
gitlab-ci, build/windows: Make crossroad scripts self-contained This make them easier to understand and to run local, as we do with native ones (They can't be run local yet, further changes will try to acomplish this a bit)
2024-05-16 09:30:15 +08:00
# FIXME: Crossroads handling of universal variables still not perfect
# The cause is: https://gitlab.gnome.org/GNOME/gimp/-/issues/11544
gitlab-ci: Make use of 'before_script' less unorthodox Since !1171 the 'before_script' was being used by me for organization, but this is at least unexpected to "mainstream" .yml pratice and can be wrong. For example, the universal variables can't be properly used this way. So, let's use 'before_script' only for the (official) purpose: save code.
2024-04-14 03:22:05 +08:00
before_script: []
gitlab-ci: Reduce redundancy on Windows cross jobs (take 1) Our crossroad jobs are too "sensible" and prone to broke so let's go gradually.
2024-04-13 07:33:27 +08:00
deps-win-x64-cross:
extends: .win-cross
rules:
gitlab-ci: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
- !reference [.win-cross, rules]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
needs: ["image-debian-x64"]
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
gitlab-ci: Re-enable pkg caching for deps-*cross job Reintroduce pkg caching for crossroad. The possibility of using it is one in thousands since we don't have distributed cache, but it's better than rely totally on MSYS2 mirrors, which can be be extremely sick sometimes.
2024-05-16 06:29:07 +08:00
variables:
XDG_CACHE_HOME: "$CI_PROJECT_DIR/.cache/"
cache:
- key: ${CI_JOB_NAME}-pkg
paths:
- .cache/
- !reference [.default, 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
script:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- bash build/windows/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:
paths:
- .local/
build/windows: Make sources downloading more neutral This makes crossroad and msys2 scripts clone without the "_" prefix, which will improve quality of life of most contributors that just clone them. Just for consistency, also remove the "_" prefix from other pices of code.
2024-07-28 18:42:02 +08:00
- babl/_build-cross/meson-logs/meson-log.txt
- gegl/_build-cross/meson-logs/meson-log.txt
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
expire_in: 2 hours
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: Reduce redundancy on Windows cross jobs (take 1) Our crossroad jobs are too "sensible" and prone to broke so let's go gradually.
2024-04-13 07:33:27 +08:00
extends: .win-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: Fix duplicate merge and push pipelines This is a well know problem documented in GitLab docs that happens when the CI isn't properly configured that was causing double pipelines in MRs. Let's fix it, and reduce some redundancy.
2024-04-21 01:34:14 +08:00
- !reference [.win-cross, rules]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
needs: ["deps-win-x64-cross", "gimp-debian-x64"]
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
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:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- bash build/windows/2_build-gimp-crossroad.sh
- bash build/windows/2_bundle-gimp-uni_base.sh
gitlab-ci: allow gimp-win-x64-cross to fail until we have a fix for #11756
2024-07-05 02:21:17 +08:00
allow_failure: true
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
artifacts:
expose_as: 'Windows zip'
paths:
- gimp-x64/
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- _build-cross/meson-logs/meson-log.txt
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
- done-dll.list
expire_in: 2 days
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) ##
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
.win:
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
extends: .default
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
rules:
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Windows Installer.*/'
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
interruptible: true
- if: '$GIMP_CI_WIN_INSTALLER != null'
- <<: *CI_RELEASE
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:
CHERE_INVOKING: "yes"
gitlab-ci: Make use of 'before_script' less unorthodox Since !1171 the 'before_script' was being used by me for organization, but this is at least unexpected to "mainstream" .yml pratice and can be wrong. For example, the universal variables can't be properly used this way. So, let's use 'before_script' only for the (official) purpose: save code.
2024-04-14 03:22:05 +08:00
# We use the same universal variables but not directly from PS
before_script: []
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
.win-a64:
extends: .win
rules:
gitlab-ci: Remove paradoxical redundancy on Windows native jobs a22393a6 introduced redundancy while removing redundancy
2024-04-13 10:00:14 +08:00
- !reference [.win, rules]
gitlab-ci, build/windows: Add MS Store job to CI The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
2023-11-18 00:08:07 +08:00
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Microsoft Store.*/'
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
interruptible: true
- if: '$GIMP_CI_MS_STORE != null'
- if: '$GIMP_CI_MSYS2_WIN_AARCH64 != 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
tags:
- windows-aarch64
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
variables:
MSYSTEM: "CLANGARM64"
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: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
# Verification to prevent the job from failing because stuck pacman (ARM only)
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: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
deps-win-a64:
extends: .win-a64
rules:
- !reference [.win-a64, rules]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
needs: []
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
stage: dependencies
script:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- C:\msys64\usr\bin\bash -lc "bash build/windows/1_build-deps-msys2.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
artifacts:
paths:
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- _install/
build/windows: Make sources downloading more neutral This makes crossroad and msys2 scripts clone without the "_" prefix, which will improve quality of life of most contributors that just clone them. Just for consistency, also remove the "_" prefix from other pices of code.
2024-07-28 18:42:02 +08:00
- babl/_build/meson-logs/meson-log.txt
- gegl/_build/meson-logs/meson-log.txt
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
expire_in: 2 hours
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-a64:
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
extends: .win-a64
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
rules:
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
- !reference [.win-a64, rules]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
needs: ["deps-win-a64"]
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
stage: gimp
script:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- C:\msys64\usr\bin\bash -lc "bash build/windows/2_build-gimp-msys2.sh"
- C:\msys64\usr\bin\bash -lc "bash build/windows/2_bundle-gimp-uni_base.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
artifacts:
paths:
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
- gimp-a64/
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- _build/meson-logs/meson-log.txt
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
- done-dll.list
gitlab-ci, build/windows: Add MS Store job to CI The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
2023-11-18 00:08:07 +08:00
# Needed by dist-installer-weekly and dist-store-weekly
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- _build/config.h
- _build/build/windows/installer/
- _build/build/windows/store/
gitlab-ci: Unify artifacts 'expire_in' time a bit more rationally For our two "development" sub-stages, the expiration is as follows: The 'dependencies' stage artifacts continues to expire in 2 hours. Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo). For "stage"/tests and "production"/dist, the expire time depends on the source of the CI pipeline. If the artifact is oriented to a 'short-span' source (e.g. MRs and commits), it expires in 2 days. If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days (we choose 8 to have a +1 day artifact just in case if something goes wrong in the weekly schedule day, which isn't rare actually).
2024-04-25 01:56:24 +08:00
expire_in: 2 days
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 x86_64 CI (native MSYS2) ##
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
.win-x64:
extends: .win
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
rules:
gitlab-ci: Remove paradoxical redundancy on Windows native jobs a22393a6 introduced redundancy while removing redundancy
2024-04-13 10:00:14 +08:00
- !reference [.win, rules]
gitlab-ci, build/windows: Add MS Store job to CI The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
2023-11-18 00:08:07 +08:00
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Microsoft Store.*/'
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
interruptible: true
- if: '$GIMP_CI_MS_STORE != null'
- if: '$GIMP_CI_MSYS2_WIN64 != 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
tags:
- win32-ps
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
variables:
MSYSTEM: "CLANG64"
deps-win-x64:
extends: .win-x64
rules:
- !reference [.win-x64, rules]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
needs: []
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
stage: dependencies
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:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- C:\msys64\usr\bin\bash -lc "bash build/windows/1_build-deps-msys2.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
artifacts:
paths:
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- _install/
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
expire_in: 2 hours
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:
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
extends: .win-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
rules:
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
- !reference [.win-x64, rules]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
needs: ["deps-win-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
stage: gimp
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:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- C:\msys64\usr\bin\bash -lc "bash build/windows/2_build-gimp-msys2.sh"
- C:\msys64\usr\bin\bash -lc "bash build/windows/2_bundle-gimp-uni_base.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
artifacts:
paths:
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
- gimp-x64/
- done-dll.list
gitlab-ci: Unify artifacts 'expire_in' time a bit more rationally For our two "development" sub-stages, the expiration is as follows: The 'dependencies' stage artifacts continues to expire in 2 hours. Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo). For "stage"/tests and "production"/dist, the expire time depends on the source of the CI pipeline. If the artifact is oriented to a 'short-span' source (e.g. MRs and commits), it expires in 2 days. If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days (we choose 8 to have a +1 day artifact just in case if something goes wrong in the weekly schedule day, which isn't rare actually).
2024-04-25 01:56:24 +08:00
expire_in: 2 days
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 x86 CI (native MSYS2) ##
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
.win-x86:
extends: .win
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
rules:
gitlab-ci: Remove paradoxical redundancy on Windows native jobs a22393a6 introduced redundancy while removing redundancy
2024-04-13 10:00:14 +08:00
- !reference [.win, 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
- if: '$GIMP_CI_MSYS2_WIN32 != null'
tags:
- win32-ps
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
variables:
MSYSTEM: "MINGW32"
gitlab-ci: Reduce redundancy on Debian native jobs * Move common things to the new .default section extensible for all jobs * Reorganize order of job elements to be way more consistent and rational: from general (pipeline/rules) to specific (job artifacts) in a liner way * The order of rules was changed to be a bit more easier to understand - Drops 'dependencies' which is redudant, and 'needs' have more options - Drop apt-cache which lost use and it is sometimes troublesome to cache + First try to boost the use of ccache in all build jobs, when possible + Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
2024-04-12 06:17:57 +08:00
CC: "ccache cc"
CXX: "ccache c++"
gitlab-ci: Use LLD linker in Debian and Flatpak jobs Following 55427487 and 85ed2847 It is a bit unusual to use 'clang' + 'GNU ld' combo. Also, lld is advertised to be way faster.
2024-06-01 00:09:33 +08:00
CC_LD: bfd
CXX_LD: bfd
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
deps-win-x86:
extends: .win-x86
rules:
- !reference [.win-x86, rules]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
needs: []
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
stage: dependencies
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:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- C:\msys64\usr\bin\bash -lc "bash build/windows/1_build-deps-msys2.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
artifacts:
paths:
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- _install/
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
expire_in: 2 hours
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:
gitlab-ci: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
extends: .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: Reduce redundancy on Windows native jobs This commit uses definitions and references to reduce repetition of CI code. Some people (like the GitLab devs?) prefer (almost imposes) this to be done in multiple .yml's using 'worfklow:' but this makes the CI way more complicated and very slow to read. So, let's just keep simple in one human readable file. --- Other changes are: - The custom native arch pipelines now they always generate a .zip package. This helps to ensure that everything is in place and facilitate testing; - The pacman update (-Syyuu) was removed since it is auto done by runners; - The ccache config was moved to .yml. This does NOT affect local builds since meson saves ccache by default for user in '%LocalAppData%/ccache'.
2024-04-11 21:39:21 +08:00
- !reference [.win-x86, rules]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
needs: ["deps-win-x86"]
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
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:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- C:\msys64\usr\bin\bash -lc "bash build/windows/2_build-gimp-msys2.sh"
- C:\msys64\usr\bin\bash -lc "bash build/windows/2_bundle-gimp-uni_base.sh"
- C:\msys64\usr\bin\bash -lc "bash build/windows/2_bundle-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:
paths:
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
- gimp-x86/
- done-dll.list
gitlab-ci: Unify artifacts 'expire_in' time a bit more rationally For our two "development" sub-stages, the expiration is as follows: The 'dependencies' stage artifacts continues to expire in 2 hours. Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo). For "stage"/tests and "production"/dist, the expire time depends on the source of the CI pipeline. If the artifact is oriented to a 'short-span' source (e.g. MRs and commits), it expires in 2 days. If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days (we choose 8 to have a +1 day artifact just in case if something goes wrong in the weekly schedule day, which isn't rare actually).
2024-04-25 01:56:24 +08:00
expire_in: 2 days
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: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
gitlab-ci: Move 'analysis' stage to a more "mainstream" position I suppose the intention of having this stage at the end was to make clear: no job depends on it. However, this place is not common or ideal but one of two: 1) before building, which is more linear; or 2) after building (the choosen) even if this isn't dynamic analysis (tests), since they are both related and some compilers and build systems do static analysis. Anyway, not after dist. The new place is a bit more clear to devs used at "build, test, deploy" praxis and maybe will be now better noticed by the existing devs before distributing. It's not perfect, since I explained above that there are two places/approaches. Obviously, the stage continues to be OPTIONAL to pass, nothing was changed. --- Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:" and made the artifacts paths of clang-format and cppcheck more consistent.
2024-04-20 09:28:16 +08:00
## Analysis ##
plug-ins: add file-plug-in testing framework Copied over from the original separate work in: https://gitlab.gnome.org/Wormnest/gimp-file-plugin-tests After that further improved and changed and added more file format tests. Added meson.build files to integrate it in our build, but we do not install it for releases.
2023-11-23 00:56:38 +08:00
file-plug-in-tests:
# FIXME: Do we need another job testing this under Windows? MSYS2 usually has
# the latest deps. It might be a good idea to test that too, maybe weekly?
extends: .default
rules:
# Don't run on release since the plug-in doesn't get installed in releases
- <<: *CI_MERGE
- <<: *CI_COMMIT
needs: ["deps-debian-x64", "gimp-debian-x64"]
stage: analysis
gitlab-ci: More little fixes regarding 'file-plug-in-tests'
2024-04-30 17:50:58 +08:00
image: $CI_REGISTRY_IMAGE:build-debian-latest
plug-ins: add file-plug-in testing framework Copied over from the original separate work in: https://gitlab.gnome.org/Wormnest/gimp-file-plugin-tests After that further improved and changed and added more file format tests. Added meson.build files to integrate it in our build, but we do not install it for releases.
2023-11-23 00:56:38 +08:00
variables:
GIMP_TESTS_DATA_FOLDER: "$CI_PROJECT_DIR/_data/gimp-test-images/"
GIMP_TESTS_LOG_FILE: "$CI_PROJECT_DIR/_log/import-tests.log"
REGRESSION_STRING: "Total number of regressions: 0"
cache:
gitlab-ci: Little changes in 'file-plug-in-tests' for consistency Some details went unnoticed by me when reviewing the MR, so Jacob authorized me to fix them separately.
2024-04-29 05:03:49 +08:00
- key: $CI_JOB_NAME
plug-ins: add file-plug-in testing framework Copied over from the original separate work in: https://gitlab.gnome.org/Wormnest/gimp-file-plugin-tests After that further improved and changed and added more file format tests. Added meson.build files to integrate it in our build, but we do not install it for releases.
2023-11-23 00:56:38 +08:00
paths:
- _data
script:
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- API_VER=$(grep GIMP_PKGCONFIG_VERSION _build/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/')
- APP_VER=$(grep GIMP_APP_VERSION _build/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/')
plug-ins: add file-plug-in testing framework Copied over from the original separate work in: https://gitlab.gnome.org/Wormnest/gimp-file-plugin-tests After that further improved and changed and added more file format tests. Added meson.build files to integrate it in our build, but we do not install it for releases.
2023-11-23 00:56:38 +08:00
- pkg-config --variable=gimplibdir gimp-${API_VER} 2>/dev/null | grep . && PLUG_IN_DIR=$(echo $(pkg-config --variable=gimplibdir gimp-${API_VER})'/plug-ins/')
- export PYTHONPATH="${PLUG_IN_DIR}test-file-plug-ins"
- export GIMP_TESTS_CONFIG_FILE="${PLUG_IN_DIR}test-file-plug-ins/tests/batch-config.ini"
- mkdir _log
- mkdir _data && cd _data
- git clone --depth=${GIT_DEPTH} https://gitlab.gnome.org/Infrastructure/gimp-test-images.git gimp-test-images
- cd ..
- cat ${PLUG_IN_DIR}test-file-plug-ins/batch-import-tests.py | gimp-console-${APP_VER} -idf --batch-interpreter python-fu-eval -b - --quit
- if [ $(grep -c "${REGRESSION_STRING}" "${GIMP_TESTS_LOG_FILE}") -ne 1 ]; then
echo "There are file import regressions. Check the log at ${GIMP_TESTS_LOG_FILE}!";
exit 1;
fi
# FIXME No export testing for now until it's more developed. A limited test
# can be done from the plug-in for bmp export.
gitlab-ci: Little changes in 'file-plug-in-tests' for consistency Some details went unnoticed by me when reviewing the MR, so Jacob authorized me to fix them separately.
2024-04-29 05:03:49 +08:00
artifacts:
paths:
- _log/
plug-ins, ci: add basic support for junit reports for... file plug-in testing. The name and location of the xml results will be the same as for the log file, but with the extension replaced by .xml. Just some basic support is added which adds failed testcases when a plug-in has a failure result, which should be the most common case of failures. Not all cases where we make errors in our test setup will generate failed testcases yet, although they should show up in the number of failures. Disabled tests won't show up as skipped tests. We also don't track time.
2024-05-03 02:36:13 +08:00
reports:
junit: "_log/import-tests.xml"
gitlab-ci: Little changes in 'file-plug-in-tests' for consistency Some details went unnoticed by me when reviewing the MR, so Jacob authorized me to fix them separately.
2024-04-29 05:03:49 +08:00
expire_in: 2 days
plug-ins: add file-plug-in testing framework Copied over from the original separate work in: https://gitlab.gnome.org/Wormnest/gimp-file-plugin-tests After that further improved and changed and added more file format tests. Added meson.build files to integrate it in our build, but we do not install it for releases.
2023-11-23 00:56:38 +08:00
gitlab-ci: Move 'analysis' stage to a more "mainstream" position I suppose the intention of having this stage at the end was to make clear: no job depends on it. However, this place is not common or ideal but one of two: 1) before building, which is more linear; or 2) after building (the choosen) even if this isn't dynamic analysis (tests), since they are both related and some compilers and build systems do static analysis. Anyway, not after dist. The new place is a bit more clear to devs used at "build, test, deploy" praxis and maybe will be now better noticed by the existing devs before distributing. It's not perfect, since I explained above that there are two places/approaches. Obviously, the stage continues to be OPTIONAL to pass, nothing was changed. --- Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:" and made the artifacts paths of clang-format and cppcheck more consistent.
2024-04-20 09:28:16 +08:00
clang-format:
extends: .default
rules:
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
- <<: *CI_MERGE
gitlab-ci: Move 'analysis' stage to a more "mainstream" position I suppose the intention of having this stage at the end was to make clear: no job depends on it. However, this place is not common or ideal but one of two: 1) before building, which is more linear; or 2) after building (the choosen) even if this isn't dynamic analysis (tests), since they are both related and some compilers and build systems do static analysis. Anyway, not after dist. The new place is a bit more clear to devs used at "build, test, deploy" praxis and maybe will be now better noticed by the existing devs before distributing. It's not perfect, since I explained above that there are two places/approaches. Obviously, the stage continues to be OPTIONAL to pass, nothing was changed. --- Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:" and made the artifacts paths of clang-format and cppcheck more consistent.
2024-04-20 09:28:16 +08:00
needs: []
stage: analysis
cache: []
script:
- apt-get update
- apt-get install -y clang-format
git
- .gitlab/run_style_check_diff.sh
allow_failure: true
artifacts:
when: on_failure
paths:
- fetch_upstream.log
- fetch_origin.log
gitlab-ci: Unify artifacts 'expire_in' time a bit more rationally For our two "development" sub-stages, the expiration is as follows: The 'dependencies' stage artifacts continues to expire in 2 hours. Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo). For "stage"/tests and "production"/dist, the expire time depends on the source of the CI pipeline. If the artifact is oriented to a 'short-span' source (e.g. MRs and commits), it expires in 2 days. If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days (we choose 8 to have a +1 day artifact just in case if something goes wrong in the weekly schedule day, which isn't rare actually).
2024-04-25 01:56:24 +08:00
expire_in: 2 days
gitlab-ci: Move 'analysis' stage to a more "mainstream" position I suppose the intention of having this stage at the end was to make clear: no job depends on it. However, this place is not common or ideal but one of two: 1) before building, which is more linear; or 2) after building (the choosen) even if this isn't dynamic analysis (tests), since they are both related and some compilers and build systems do static analysis. Anyway, not after dist. The new place is a bit more clear to devs used at "build, test, deploy" praxis and maybe will be now better noticed by the existing devs before distributing. It's not perfect, since I explained above that there are two places/approaches. Obviously, the stage continues to be OPTIONAL to pass, nothing was changed. --- Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:" and made the artifacts paths of clang-format and cppcheck more consistent.
2024-04-20 09:28:16 +08:00
cppcheck:
extends: .default
rules:
- if: '$GIMP_CI_CPPCHECK != null'
needs: []
stage: analysis
cache: []
script:
- apt-get update
- apt-get install -y cppcheck
- cppcheck -q -j8 --enable=all --force --output-file=cppcheck.xml --xml --xml-version=2
build/windows: Make sources downloading more neutral This makes crossroad and msys2 scripts clone without the "_" prefix, which will improve quality of life of most contributors that just clone them. Just for consistency, also remove the "_" prefix from other pices of code.
2024-07-28 18:42:02 +08:00
-i _build -i _build-cross -i babl -i gegl -i _install -i .local -i .cache -i _ccache -i gimp-x64 .
gitlab-ci: Move 'analysis' stage to a more "mainstream" position I suppose the intention of having this stage at the end was to make clear: no job depends on it. However, this place is not common or ideal but one of two: 1) before building, which is more linear; or 2) after building (the choosen) even if this isn't dynamic analysis (tests), since they are both related and some compilers and build systems do static analysis. Anyway, not after dist. The new place is a bit more clear to devs used at "build, test, deploy" praxis and maybe will be now better noticed by the existing devs before distributing. It's not perfect, since I explained above that there are two places/approaches. Obviously, the stage continues to be OPTIONAL to pass, nothing was changed. --- Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:" and made the artifacts paths of clang-format and cppcheck more consistent.
2024-04-20 09:28:16 +08:00
- mkdir report
- cppcheck-htmlreport --source-dir=. --title=gimp --file=cppcheck.xml --report-dir=report
artifacts:
paths:
- report/
gitlab-ci: Unify artifacts 'expire_in' time a bit more rationally For our two "development" sub-stages, the expiration is as follows: The 'dependencies' stage artifacts continues to expire in 2 hours. Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo). For "stage"/tests and "production"/dist, the expire time depends on the source of the CI pipeline. If the artifact is oriented to a 'short-span' source (e.g. MRs and commits), it expires in 2 days. If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days (we choose 8 to have a +1 day artifact just in case if something goes wrong in the weekly schedule day, which isn't rare actually).
2024-04-25 01:56:24 +08:00
expire_in: 8 days
gitlab-ci: Move 'analysis' stage to a more "mainstream" position I suppose the intention of having this stage at the end was to make clear: no job depends on it. However, this place is not common or ideal but one of two: 1) before building, which is more linear; or 2) after building (the choosen) even if this isn't dynamic analysis (tests), since they are both related and some compilers and build systems do static analysis. Anyway, not after dist. The new place is a bit more clear to devs used at "build, test, deploy" praxis and maybe will be now better noticed by the existing devs before distributing. It's not perfect, since I explained above that there are two places/approaches. Obviously, the stage continues to be OPTIONAL to pass, nothing was changed. --- Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:" and made the artifacts paths of clang-format and cppcheck more consistent.
2024-04-20 09:28:16 +08:00
gitlab-ci: add a distribution step. I don't add this at the end of the distcheck job to make the interface clearer, and also because the distcheck job will have full build artifacts (allowing to debug a failing distcheck if necessary), whereas the `sources` job will just publish tarballs and SHA256 sums generated from these tarballs. Simple, clean.
2020-08-07 22:41:05 +08:00
## Ready-to-distribute ##
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: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
extends: .default
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:
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
- <<: *CI_COMMIT
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
- if: '$GIMP_CI_SOURCES != null'
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
- <<: *CI_RELEASE
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +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
stage: distribution
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
cache: []
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
script:
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- mv _build/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: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
artifacts:
paths:
- gimp-*.tar.xz
- gimp-*.tar.xz.SHA256SUMS
- gimp-*.tar.xz.SHA512SUMS
expire_in: 2 days
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:
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
extends: .default
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
rules:
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
- <<: *CI_COMMIT
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
- if: '$GIMP_CI_SOURCES != null'
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
- <<: *CI_RELEASE
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
needs: ["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
stage: distribution
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
cache: []
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:
gitlab-ci: Move 'image:' from deprecated global to .default
2024-04-14 18:48:25 +08:00
- apt-get update
- apt-get install -y xz-utils
build/windows: Make sources downloading more neutral This makes crossroad and msys2 scripts clone without the "_" prefix, which will improve quality of life of most contributors that just clone them. Just for consistency, also remove the "_" prefix from other pices of code.
2024-07-28 18:42:02 +08:00
- BABL_VER=$(grep BABL_VERSION babl/_build/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/') &&
BABL_API_VER=$(grep BABL_API_VERSION babl/_build/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/') &&
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
DIR_NAME=babl-api-docs-$BABL_VER &&
mkdir $DIR_NAME &&
mv "${GIMP_PREFIX}/share/doc/babl-$BABL_API_VER" $DIR_NAME/ &&
TAR_NAME="$DIR_NAME.tar.xz" &&
tar --dereference -cJf ${TAR_NAME} $DIR_NAME &&
sha256sum $TAR_NAME > ${TAR_NAME}.SHA256SUMS &&
gitlab-ci: generating tarballs for babl and GEGL API reference documentation.
2023-08-12 23:33:54 +08:00
sha512sum $TAR_NAME > ${TAR_NAME}.SHA512SUMS
build/windows: Make sources downloading more neutral This makes crossroad and msys2 scripts clone without the "_" prefix, which will improve quality of life of most contributors that just clone them. Just for consistency, also remove the "_" prefix from other pices of code.
2024-07-28 18:42:02 +08:00
- GEGL_MAJ_VER=$(grep GEGL_MAJOR_VERSION gegl/_build/config.h |head -1 |sed 's/^[^0-9]*\([0-9]*\).*$/\1/') &&
GEGL_MIN_VER=$(grep GEGL_MINOR_VERSION gegl/_build/config.h |head -1 |sed 's/^[^0-9]*\([0-9]*\).*$/\1/') &&
GEGL_MIC_VER=$(grep GEGL_MICRO_VERSION gegl/_build/config.h |head -1 |sed 's/^[^0-9]*\([0-9]*\).*$/\1/') &&
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +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 &&
mv "${GIMP_PREFIX}/share/doc/gegl-$GEGL_API_VER" $DIR_NAME/ &&
TAR_NAME="$DIR_NAME.tar.xz" &&
tar --dereference -cJf ${TAR_NAME} $DIR_NAME &&
sha256sum $TAR_NAME > ${TAR_NAME}.SHA256SUMS &&
gitlab-ci: generating tarballs for babl and GEGL API reference documentation.
2023-08-12 23:33:54 +08:00
sha512sum $TAR_NAME > ${TAR_NAME}.SHA512SUMS
build: Simplify all the arch stuff The ARTIFACTS_SUFFIX is being dropped on building scripts because: 1) This will make possible to further simplify Installer scripts in other commit 2) There is no script that uses multi-arch _build/_install at same time on CI However, there are two use cases: to build Debian and flatpak; and, on Win, to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche. I suppose that people who build on Debian (or other dev-oriented distro) willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime) + two gimp prefixes (out of sandbox and sandbox) due to huge storage use. Why someone would want to build with emulation on Win ARM64 I don't know. Anyway, people that know how to do this stuff probably can change the .sh. 3) When building locally, the contributor doesn't need to know the arch at all. Indeed, without this suffix, the scripts are inline with gimp-web-devel and prevent some first-sight confusion when reading them that I've seen on IRC. 4) These arch suffixes can be understood as '_install-*' being distributable which is not true. So, without this suffix we could make more clear what is a package (when GitLab fix the glob bug in 'expose_as' someday). --- Despite .gitlab-ci.yml not being a script, it needed to be touched too because cross scripts depends on Debian jobs due to gimp-data MR.
2024-07-20 06:54:58 +08:00
- GIMP_VER=$(grep GIMP_VERSION _build/config.h | head -1 | sed 's/^.*"\([^"]*\)"$/\1/') &&
APP_VER=$(echo $GIMP_VER | sed 's/\([0-9]\+\.[0-9]\+\)\..*/\1/') &&
DIR_NAME=gimp-api-docs-$GIMP_VER &&
mkdir $DIR_NAME &&
mv "${GIMP_PREFIX}/share/doc/gimp-$APP_VER" $DIR_NAME/reference &&
mv _build/devel-docs/g-ir-docs $DIR_NAME/ &&
TAR_NAME="$DIR_NAME.tar.xz" &&
tar --dereference -cJf ${TAR_NAME} $DIR_NAME &&
sha256sum $TAR_NAME > ${TAR_NAME}.SHA256SUMS &&
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
sha512sum $TAR_NAME > ${TAR_NAME}.SHA512SUMS
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
artifacts:
paths:
- 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
- gimp-api-docs-*.tar.xz
- gimp-api-docs-*.tar.xz.SHA256SUMS
- gimp-api-docs-*.tar.xz.SHA512SUMS
expire_in: 2 days
gitlab-ci, build/linux: Move Flatpak CI code to scripts that works This will make easier to debug problems locally if needed and have the potential to reduce the first barrier for Linux newbies.
2024-05-21 22:53:34 +08:00
include: 'https://gitlab.gnome.org/GNOME/citemplates/raw/master/flatpak/flatpak_ci_initiative.yml'
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
dist-flatpak-weekly:
gitlab-ci, build/linux: Move Flatpak CI code to scripts that works This will make easier to debug problems locally if needed and have the potential to reduce the first barrier for Linux newbies.
2024-05-21 22:53:34 +08:00
extends:
- .default
- .publish_nightly
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
rules:
gitlab-ci: Expose .flatpak as artifact from the distribution job Completing d09a2a6f, since the dist job wasn't added to MR pipelines that time Note: this doesn't change the actual behavior. The job will upload to nightly repo only when triggered from schedule pipelines. I repeat, nothing changed. What is new is that the .flatpak bundle now is an artifact from dist job, since: - Despite the name, it isn't a real bundle, so no need to be only in gimp stage - In dist, it reduces storage use because only the .flatpak file lasts 8 days, not the .tar and other files from gimp job which lasts 2 days (5495483c)
2024-05-26 22:32:41 +08:00
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Flatpak package.*/'
interruptible: true
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
- if: '$GIMP_CI_FLATPAK != null'
gitlab-ci: Drop 'packaging' stage This stage was introduced in 076e4d68 and it fulfilled well its purpose. But the side effects were: more (sometimes slow) uploading and downloading of packages and artifacts. Even if we have caching, this is far from ideal. Now, the so-called "packaging" jobs were moved inside in the "build" jobs. The advantages are: just one pacman install (ideally cached from deps job); direct packaging without waiting for upload/download; and less confusion, since "packaging" naming was implying that the .zips are somewhat official, which isn't totally true, and sometimes overlaps the dist/deploy concept. --- Also, the flatpak job now uses config.h instead of triggering a GIMP build. In other words, I'm reverting part of my work in some old commits.
2024-04-16 08:12:39 +08:00
needs: ["gimp-flatpak-x64"]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
stage: distribution
gitlab-ci, build/linux: Move Flatpak CI code to scripts that works This will make easier to debug problems locally if needed and have the potential to reduce the first barrier for Linux newbies.
2024-05-21 22:53:34 +08:00
cache: []
gitlab-ci: Expose .flatpak as artifact from the distribution job Completing d09a2a6f, since the dist job wasn't added to MR pipelines that time Note: this doesn't change the actual behavior. The job will upload to nightly repo only when triggered from schedule pipelines. I repeat, nothing changed. What is new is that the .flatpak bundle now is an artifact from dist job, since: - Despite the name, it isn't a real bundle, so no need to be only in gimp stage - In dist, it reduces storage use because only the .flatpak file lasts 8 days, not the .tar and other files from gimp job which lasts 2 days (5495483c)
2024-05-26 22:32:41 +08:00
script:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- bash build/linux/flatpak/3_dist-gimp-flatpak.sh
gitlab-ci: Drop 'packaging' stage This stage was introduced in 076e4d68 and it fulfilled well its purpose. But the side effects were: more (sometimes slow) uploading and downloading of packages and artifacts. Even if we have caching, this is far from ideal. Now, the so-called "packaging" jobs were moved inside in the "build" jobs. The advantages are: just one pacman install (ideally cached from deps job); direct packaging without waiting for upload/download; and less confusion, since "packaging" naming was implying that the .zips are somewhat official, which isn't totally true, and sometimes overlaps the dist/deploy concept. --- Also, the flatpak job now uses config.h instead of triggering a GIMP build. In other words, I'm reverting part of my work in some old commits.
2024-04-16 08:12:39 +08:00
artifacts:
expose_as: 'Linux flatpak'
paths:
- gimp-git.flatpak
gitlab-ci: Unify artifacts 'expire_in' time a bit more rationally For our two "development" sub-stages, the expiration is as follows: The 'dependencies' stage artifacts continues to expire in 2 hours. Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo). For "stage"/tests and "production"/dist, the expire time depends on the source of the CI pipeline. If the artifact is oriented to a 'short-span' source (e.g. MRs and commits), it expires in 2 days. If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days (we choose 8 to have a +1 day artifact just in case if something goes wrong in the weekly schedule day, which isn't rare actually).
2024-04-25 01:56:24 +08:00
expire_in: 8 days
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
dist-installer-weekly:
extends: .win
rules:
- !reference [.win, rules]
gitlab-ci: Drop 'packaging' stage This stage was introduced in 076e4d68 and it fulfilled well its purpose. But the side effects were: more (sometimes slow) uploading and downloading of packages and artifacts. Even if we have caching, this is far from ideal. Now, the so-called "packaging" jobs were moved inside in the "build" jobs. The advantages are: just one pacman install (ideally cached from deps job); direct packaging without waiting for upload/download; and less confusion, since "packaging" naming was implying that the .zips are somewhat official, which isn't totally true, and sometimes overlaps the dist/deploy concept. --- Also, the flatpak job now uses config.h instead of triggering a GIMP build. In other words, I'm reverting part of my work in some old commits.
2024-04-16 08:12:39 +08:00
needs: ["gimp-win-a64", "gimp-win-x64", "gimp-win-x86"]
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
stage: distribution
tags:
build/windows: Fix Installer after native x64 and arm64 TWAIN drop Native arm64 and x64 TWAIN binaries are not built anymore. No need to discard at dist time what doesn't exist. (32-bit TWAIN not affected) Also, start to using our own ARM64 runners to do the dist. This is more reliable since the shared x64 runners can (and indeed) cause long queue.
2024-04-22 20:44:39 +08:00
- windows-aarch64
gitlab-ci, build: Make DWARF (.debug) symbols splitting an Installer only script Splitted .debug are not needed by crossbuilds, and breaks .msix certification.
2024-05-24 01:28:58 +08:00
variables:
MSYSTEM: "CLANGARM64"
gitlab-ci: Fix Installer job using cache
2024-05-01 00:37:10 +08:00
cache: []
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
script:
build: Make scripts numbering and storing consistent The numbering is now inline with actual the order of jobs on CI to make easier to understand what the numbers represent. To understand why bundling is number 2 see: d09a2a6f and 2dc6f411 The storing of Windows scripts was changed to make easier to call them, to better convey that they work outside CI and to be consistent with other build/ subdirectories.
2024-06-21 01:31:10 +08:00
- C:\msys64\usr\bin\bash -lc "bash build/windows/2_bundle-gimp-uni_sym.sh"
- build/windows/installer/3_dist-gimp-inno.ps1 | Out-File -FilePath installer.log
gitlab-ci: Overall cosmetic change following e96b751e Also, drops 'apt-cache' caching since after some experimenting with !1171 this proved to be of little use; and reorganize some dist and analysis jobs.
2024-04-13 03:20:20 +08:00
artifacts:
expose_as: 'Windows exe'
paths:
- build/windows/installer/_Output/
- installer.log
gitlab-ci: Unify artifacts 'expire_in' time a bit more rationally For our two "development" sub-stages, the expiration is as follows: The 'dependencies' stage artifacts continues to expire in 2 hours. Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo). For "stage"/tests and "production"/dist, the expire time depends on the source of the CI pipeline. If the artifact is oriented to a 'short-span' source (e.g. MRs and commits), it expires in 2 days. If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days (we choose 8 to have a +1 day artifact just in case if something goes wrong in the weekly schedule day, which isn't rare actually).
2024-04-25 01:56:24 +08:00
expire_in: 8 days
gitlab-ci, build/windows: Add MS Store job to CI The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
2023-11-18 00:08:07 +08:00
dist-store-weekly:
extends: .win
rules:
- if: '$CI_MERGE_REQUEST_LABELS =~ /.*5. Microsoft Store.*/'
gitlab-ci: Fix custom builds being interrupted This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
2024-04-25 08:00:39 +08:00
interruptible: true
- if: '$GIMP_CI_MS_STORE != null'
- <<: *CI_RELEASE
gitlab-ci, build/windows: Add MS Store job to CI The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
2023-11-18 00:08:07 +08:00
needs: ["gimp-win-a64", "gimp-win-x64"]
stage: distribution
tags:
- win32-ps
cache: []
script:
build/windows: Refactor MSIX .ps1 a bit to not impose strict SDK or .msixbundle The original script required a specific WinSDK version. Now, it autodetects. This is useful if we need to move to another runner and welcome locally too. Also, downloading the arm64 artifact was mandatory to get a x64 msix, which is silly. Now, packagers are free to package to either arm64 or x64 alone. This is useful locally but could be useful on CI too when some arch fail(?).
2024-07-14 02:49:40 +08:00
- build\windows\store\3_dist-gimp-winsdk.ps1 | Out-File -FilePath winsdk.log
gitlab-ci, build/windows: Add MS Store job to CI The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
2023-11-18 00:08:07 +08:00
artifacts:
expose_as: 'Windows msix'
paths:
- build/windows/store/_Output/
build/windows: Refactor MSIX .ps1 a bit to not impose strict SDK or .msixbundle The original script required a specific WinSDK version. Now, it autodetects. This is useful if we need to move to another runner and welcome locally too. Also, downloading the arm64 artifact was mandatory to get a x64 msix, which is silly. Now, packagers are free to package to either arm64 or x64 alone. This is useful locally but could be useful on CI too when some arch fail(?).
2024-07-14 02:49:40 +08:00
- winsdk.log
gitlab-ci: Unify artifacts 'expire_in' time a bit more rationally For our two "development" sub-stages, the expiration is as follows: The 'dependencies' stage artifacts continues to expire in 2 hours. Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo). For "stage"/tests and "production"/dist, the expire time depends on the source of the CI pipeline. If the artifact is oriented to a 'short-span' source (e.g. MRs and commits), it expires in 2 days. If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days (we choose 8 to have a +1 day artifact just in case if something goes wrong in the weekly schedule day, which isn't rare actually).
2024-04-25 01:56:24 +08:00
expire_in: 8 days