In commit f9526f39a1 (ci: Add bzr and p4 to Debian and Fedora base
images, 2022-02-21) we checked the SHA-256 hash of the Perforce binary.
However, content at the download URL has changed in just the last few
weeks, so we cannot consider it stable.
The `native` architecture compiles for the host's GPUs, but our CI jobs
may may run on hosts with GPUs newer than supported by their version of
the CUDA toolkit. Add an undocumented environment variable to tell
CMake to clamp the native architecture to that supported by the toolkit.
Without this, we may try to compile for architectures not supported by
the CUDA Toolkit, which fails. Since commit d1b48bfabd (CUDA: Add
support for CUDA_ARCHITECTURES=native, 2022-03-04), our CUDA 9.2 CI job
fails when it runs on a CI host with a GPU architecture newer than that
CUDA 9.2 supports. Clamping the architecture level fixes that.
Do not document this clamp behavior publicly, at least for now.
Users can be responsible for building with a CUDA toolkit recent
enough to support their host's GPUs.
Issue: #22375
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.
The actual compiler is too large to put in the base image.
Install its dependencies so we can download and run it in a job.
Note that Swift binaries are only available for `x86_64`.
Perforce does not provide binaries for `aarch64`, so leave it out for
that architecture.
Fedora now packages `breezy` instead of the original `bzr`. Note that
breezy does not have the xmloutput plugin needed for `bzr log --xml`.
This is also why commit 1972a75536 (Tests: Drop CTestUpdate.BZR test
check for xmloutput plugin, 2022-02-04) observed that there is no
`bzr xmlplugins` command.
Previously we used a complicated heuristic to decide whether or not to
run the MFC test, but it sometimes decided incorrectly to run the test.
Since that was first written, we have developed a convention for other
tests to enable them via undocumented cache entries that are added only
on machines known to meet the tests' requirements. Do that for MFC.
We should have at least one CI job in merge request pipelines that
builds CMake with assertions enabled. We avoid using the `Debug`
configuration in order to keep CI artifacts small, so instead use
the `Release` configuration without `-DNDEBUG`.
Avoid searching for a Java installation on Windows hosts.
This will allow some CI hosts to have Java for other projects.
We already do this on macOS. While at it, clarify the macOS setting.
Since commit 3b9975d9b5 (ci: Add JOM nightly CI job, 2021-11-17) the
`ExternalProject` test often fails spuriously with an internal error
message from JOM. Exclude it for now pending further investigation.
Prior to covering JOM in CI, it was covered by a standalone nightly
build that excluded the `ExternalProject` test for the same reason.
This helps to maximize the amount of information visible in the GitLab
web interface.
Also document their meaning in the developer documentation and in the CI
configuration file directly.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/8496
This helps to maximize the amount of information visible in the GitLab
web interface.
Also document their meaning in the developer documentation and in the CI
configuration file directly.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/8496
Brad King