We've removed use of KWSys ConsoleBuf in post-4.0 commit 3e88020aed
(StdIo: Replace uses of KWSys ConsoleBuf with StdIo::Console,
2025-05-08). There is no need to run its test anymore.
Windows-Terminal-Issue: https://github.com/microsoft/terminal/issues/18748
CUDA 12.8 deprecated support for compute architectures below 75.
Presumably support will be removed from a future version of the
CUDA Toolkit. Jobs using such a future version of CUDA will not
be able to compile support for CUDA architectures below 75, so
they will not be able to run on older hardware. In preparation,
our CI runners now have `cuda-arch-#` tags for the architectures
they support. Jobs may then be tagged with the minimum architecture
on which they can run.
Tag each job with the highest of the following requirements:
* Most of CMake's tests use the CUDA compiler's default architecture,
which is based on the version the CUDA toolkit.
* For Clang we currently select architecture 52 if supported by the
CUDA toolkit, even if that toolkit's NVCC defaults to an older arch.
* The `CudaOnly.Architecture` test uses a specific architecture
configured by each CI job.
CUDA 12.8 deprecates architectures below 75. Presumably a future
version will remove it. Prepare infrastructure to avoid relying on
hard-coded arch 52 in this test.
CUDA 12.8 deprecated support for compute architectures below 75.
Presumably support will be removed from a future version of the
CUDA Toolkit. Jobs using such a future version of CUDA will not
be able to compile support for CUDA architectures below 75, so
they will not be able to run on older hardware. In preparation,
our CI runners now have `cuda-arch-#` tags for the architectures
they support. Jobs may then be tagged with the minimum architecture
on which they can run.
Tag each job with the highest of the following requirements:
* Most of CMake's tests use the CUDA compiler's default architecture,
which is based on the version the CUDA toolkit.
* For Clang we currently select architecture 52 if supported by the
CUDA toolkit, even if that toolkit's NVCC defaults to an older arch.
* The `CudaOnly.Architecture` test uses a specific architecture
configured by each CI job.
CUDA 12.8 deprecates architectures below 75. Presumably a future
version will remove it. Prepare infrastructure to avoid relying on
hard-coded arch 52 in this test.
In Xcode 7.3 and above, the `TEST_HOST` setting causes Xcode to
implicitly place the test module inside the executable bundle regardless
of the module's own location settings. Since commit a364d2513a (Xcode:
Fixup XCTest bundle location for Xcode 7.3, 2016-03-25, v3.5.2~6^2) we
explicitly tell CMake to put the test module in the same location so
that generator expressions used by `xctest_add_test` agree with where
Xcode actually puts it. In Xcode 16 and above, our explicit location
settings for the test module conflict with Xcode's `TEST_HOST` rules,
causing errors about multiple commands producing the same path.
Fix this by dropping CMake's explicit location for the test module
unless needed to match a project-specified location for the testee.
Instead, teach `xctest_add_test` to express the xctest module location
selected by `TEST_HOST` by using generator expressions referencing the
testee bundle.
Fixes: #26301Fixes: #26514
Enable it on `macos-arm64` jobs and disable it on `macos-x86_64` jobs.
Since the default detection pierces Rosetta, it cannot be used in CI
where we might build and test on different hosts.
The problem described in commit ec682ff22a (ci: Update to ROCm 6 HIP on
Fedora 41, 2024-12-02, v3.31.2~3^2) occurs here too. Move the CI work
directory to a path without spaces.
Issue: #25932
Commit messages in the CMake repo may have Git hashes that can trigger
false positives in the `typos` checker.
Revert commit ddebf4653d (ci: Do not check commit messages with 'typos'
due to false positives, 2025-02-07). Instead, copy the top-level config
file to a temporary location, add a configuration option to mark
10-hex-digit identifiers as always valid, and pass it to `typos` at the
commit checking phase.
Since commit c3777c1536 (ci: Extend spellcheck job with 'typos' tool,
2025-01-04) we check spelling with `typos` in addition to the
pre-existing check with `codespell`. Unlike `codespell`, `typos` can
find typos in combined identifiers, e.g., `PascalCase` or `snake_case`.
That works well for code, but in commit messages it can trigger on
"words" in the middle of commit hashes.
- Use the correct path for the DNF cache.
- There is not much sense in having a DNF cache image separately when
the only `RUN` command is to install required packages.
- Do not waste time looking for pre-built images for Fedora.
Tell to `rvm` to always build from sources.
- No need to update startup files (in the intermediate image).
- Exclude useless (documentation) files from the final archive.
It improves parallelization and speeds up the build.
Since downloading is a quick task, put the results to the final image
at the beginning to avoid waiting for other (longer) tasks.
So, images would really use it again!
This reduce build time up to 25%!
This was accidentally broken by commit 46d89b8524 (ci: update Linux
image to Fedora 41, 2024-10-23, v3.31.0-rc3~7^2~2) by misdiagnosing an
error.
In order to share `.codespellrc` between our CI checks and `pre-commit`
checks, we need to match paths without the leading `./`. Convert to a
`bash` script so we can use `dotglob` to pass paths explicitly.
Unfortunately this means we can no longer run `codespell` manually with
no arguments. Instead we can run `.gitlab/ci/codespell.bash`.
In commit fff8e3f6f3 (ci: Rebuild Fedora 41 image with updates,
2024-11-11, v3.31.1~20^2) we specified an exact version of the `flang`
package to update beyond the default at the time. Revert that now that
the default is newer.
We did this previously on Linux and Windows:
* commit 45feab3c00 (gitlab-ci: enable assertions on fedora34-ninja jobs,
2022-01-31, v3.23.0-rc1~37^2)
* commit bec34592a6 (ci: Enable assertions in CMake build job on Windows,
2024-12-19)
The macOS build jobs were already building the `Release` configuration
by default. Make it explicit to be sure we use these flags.
Brad King