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.
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.
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.
A release pipeline is always created by manual execution of a pipeline
schedule. Require the initial pipeline jobs to be started manually too
so that we can later add separate components to play separately.
Redefine the `CMAKE_CI_PACKAGE` pipeline schedule variable to
indicate whether it is for a development version (`dev`) or a
release version (`v[0-9]...`). Use this to automatically turn
package upload jobs on or off without having to edit the jobs
in `.gitlab-ci.yml` for release branches.
Apply the rules from commit ff72dbfb14 (gitlab-ci: configure rules to
enable continuous builds of staged MRs, 2020-09-30, v3.19.0-rc1~70^2~1)
and commit 71665c8cb9 (gitlab-ci: Clarify conditions enabling jobs for
continuous build of stage, 2021-05-05, v3.21.0-rc1~218^2) to dependent
jobs too.
Previously we ran manual jobs automatically in the `cmake/cmake`
project integration branches. Change this to happen only when
the pipeline is created by a schedule.
Also, start automatic jobs in scheduled pipelines without delay.
661ff7f2d8 gitlab-ci: equally delay all jobs on integration branches
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !6013
When running a pipeline on an integration branch in `cmake/cmake`, delay
the lint jobs just as much as all the others. This avoids starting them
unnecessarily during a sequence of merges over a short time range.
GitLab 13.3 started creating MR pipelines in the parent project of a MR
from a fork, at least when the MR submitter is a developer in the parent
project. If the pipeline is associated with a MR, we should use the
corresponding rules regardless of which project hosts the pipeline.
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.
