I don’t think we should count on using earlier version of GitHub Actions Images, we should aim to either have our own build of image, or a script that set up an environment ideally throughout LTS Ubuntu environment, I would vastly prefer the later one unless there’s special cases.
Setting up a specific version of compiler is the perfect situation for “special case” here, it need a potentially lengthy setup script and could be easily broken by running on another os version.
The official documentation indicate support for the last 2 versions of the OS. Ubuntu runs on a 2 year release cycle. So 22 would still be supported for 2 years till when 26 comes out.
Yes you can direct GitHub Action to use 22 instead of latest.
I don’t think we should discourage use of latest, being on latest encourage one to write scripts that works across distributions. If we have too much assumption on the ubuntu version, we will need to evaluate os versions manually ever-so-often, and we may have a lot of headache across the entire org every 2 years when an image get deprecated. I think most of our libraries are going to be maintained for more than 2 years (or 4 years if using 24.04), consider a project is still maintained for two C++ release cycle (6 years!) after its adopted.
In the case of reusing GitHub image. The official documentation indicate native support for 3 latest major versions for GNU/ Clang, that would be GCC 11-14 (about 3 years span), Clang 16-19 (about 1.5 year span) in principle. But the actual versions varies across images and seem to mean “the latest 3 versions when the image was initially created” in practice.
The image specific documentation can be found here: for ubuntu 24.04, for ubuntu 22.04.
| Version | GNU | Clang |
|---|---|---|
| 22.04 | 10.5.0, 11.4.0, 12.3.0 | 13.0.1, 14.0.0, 15.0.7 |
| 24.04 | 12.3.0, 13.3.0, 14.2.0 | 16.0.6, 17.0.6, 18.1.3 |
Note that clang 15 is entirely omitted. This is because clang seem to operate on a 6 month release schedule. It takes 4 release cycle for clang for 1 ubuntu release, and GitHub officially packs 3 releases, so one major version of clang is dropped every 2 years. That means clang 19, the latest major release since sept 24 won’t be included in 24.04, and may never be included in 26.
This doesn’t sound like too poor of a support window. Though we do lose the control over the upper and lower range of compiler versions to support. In previous discussions we reached a consensus that we should still support C++17 (and lower) when appropriate. The earliest clang release included in GitHub image is 13, which is released in 2022, we would ideally want to support an earlier version, if someone is stuck on C++17, they probably are stuck on an earlier version of compiler as well.
On top of the loss of control, we will also need to track all these releases and know which image to use. It will suffer the same problem as the “everything breaks every 2 years” problem. I see every repo checking against every recent major compiler version, but I don’t see all repo owners understanding, checking and keeping up with all these life-cycles and support status.
I think its pretty clear we will have to maintain some kind of install script to test across compiler versions. These setup scripts sometimes breaks across ubuntu releases and have caveats, e.g. llvm-16 and lower cannot be installed on ubuntu 24.04 directly using the llvm install script, higher gnu versions are not available on 20.04 universe apt repo.
If all repos are expected to test across compiler versions, we might as well move the install script into a docker container.