Split packaging on Windows into dedicated jobs that run with access to
an EV signing certificate.
Prior to commit 0929221ca3 (gitlab-ci: Simplify Windows packaging
pipeline, 2023-02-28, v3.26.0-rc5~3^2~3) we had separate packaging jobs,
but they did not run in release packaging pipelines. Restore them, and
run them in both nightly and release packaging pipelines.
Some jobs will run in a build directory other than
$CI_PROJECT_DIR/build, and will produce artifacts in a different
directory. Add a variable specifying where to find the artifacts, and
set it to build/ by default.
These artifacts need to be manually signed before distribution.
Move them to a dedicated `unsigned/` directory to avoid accidental
distribution without signing.
In commit 4c7c66dcf5 (gitlab-ci: Add jobs to make Windows x86_64 and
i386 packages, 2022-05-19, v3.24.0-rc1~112^2) we used a separate Windows
packaging job in nightly packaging pipelines. It did not run in release
pipelines, where we need to run the final packaging step manually with
signing. Simplify nightly packaging pipelines by running `cpack` at the
end of the build job as we do for other platforms.
For release packaging pipelines, create an archive of the files needed
to build a package, and present this as the built "package" on Windows.
Base it on the approach from commit 4c7c66dcf5 (gitlab-ci: Add jobs to
make Windows x86_64 and i386 packages, 2022-05-19). Leave out the
packaging and upload steps for now because they are only for the nightly
binaries, and will need a new release of CPack to pass the `arm64`
architecture to WiX.
Issue: #21902
Name the `.zip` file that GitLab CI uses to hold the package artifacts.
Use a different name for each platform/architecture combination so that
we can download them all to a single local directory without conflicts.
Run CPack in a separate job for nightly binaries, and not at all for
release binaries. Unlike macOS disk images (.dmg), we cannot sign the
binaries inside Windows installers (.msi) after-the-fact. Instead,
produce enough artifacts from the build job to sign and package release
binaries manually.
Port build settings from `Utilities/Release/win/x86/Dockerfile` and its
helper scripts.
The minimum CMake version for Qt6 is 3.16, so all the calls to
cmake_minimum_required() are updated here to enforce that
minimum. This will avoid any CMake version-related warnings
from Qt.
Avoid hard-coding Qt5 where the tests could now be using
Qt5 or Qt6.
Fixes: #22188
In order to support modern macOS features like Dark Mode, we need to use
Qt 5.15, which requires macOS 10.13. However, we still want to support
macOS 10.10 as well, for which we need to use Qt 5.9. Build separate
macOS packages for these use cases.
Fixes: #21606
Issue: #20825
Also add comments for sections to make it easier to figure out what's
going on.
Also rename the `cmake_test_unix_package` to be Linux-specific since it
actually is.
