| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| | |
b691906d27 gitlab-ci: Build qthelp-format release documentation for cmake.org
1ceec19c20 gitlab-ci: Add objects.inv to cmake.org html documentation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7146
|
| |
| |
| |
| |
| | |
Previously the qthelp-format release documentation on `cmake.org` was
built manually.
|
|\ \
| |/ |
|
| | |
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| | |
eb410615f2 gitlab-ci: start release package pipelines manually
3a90800a9c gitlab-ci: simplify package pipeline job conditions
9a1b301c85 gitlab-ci: add sanity check to upload jobs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7143
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Use the job stage to distinguish upload jobs instead of an
explicit variable.
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| | |
b20a19fca1 Merge branch 'backport-3.22-ci-package-uploads' into ci-package-uploads
cb44e0d47c gitlab-ci: distinguish release and development pipeline schedules
3a9a9a3ace gitlab-ci: clarify name of package upload job template
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7142
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Configure rules to allow jobs for continuous builds to be enabled on a
project that configures a specific branch this purpose.
|
| |
|
| |
|
|
|
|
|
| |
This can be added to any other platform's package by reusing the
artifact.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This avoids making busted jobs if a prerequisite fails.
|
|
|
|
| |
YAML anchors are not supported across include files.
|
| |
|
|
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.
|