I am trying to find a better way to maintain our CI, but have heard the following conflicting advice.
My team is required to version pin our dependencies so builds are (mostly) reproducible, and then we have control over when versions change. A rolling release is not suitable for our production builds.
Recommendations from various CMake talks and Craig Scott’s book:
CMake developers - Use the latest CMake you can get ahold of
CMake minimum version - Specify the minimum version of the features you actually use
CMake CI - Run a build with the latest released CMake version, and another build at the same version as you set in cmake_minimum_required to ensure you haven’t added any features that are not available in the minimum version you declare.
To meet all these requirements, we decided to make use of CMake’s apt repository to install a recent version of CMake (3.25 is what we currently pin), and we update it as we need. That said, the kitware apt repository has broken our CI at least twice, by removing a package that we had pinned.
As I noted below, the minor versions of 3.23 and 3.24 are no longer available at all. Our CI used to pin 3.24 but then one day it spontaneously stopped working when that package was not available.
Being able to use new versions of CMake without having to compile from source is really excellent, but there does not seem to be any predictability on which minor versions will be maintained or not in the apt repo, or when versions will be removed.
In order to satisfy the constraints and recommendations, what would you all recommend such that our CI continues to work reliably without surprises?
- We mirror CMake, building debians in our CI and hosting them internally, but this is not ideal because we don’t have infrastructure for debian packages
- Going back to compiling CMake from source on builds, but this is a significant time cost on each build
- Kitware can provide EOL dates for each of the versions they host which would allow us to plan around removals