@@ -259,20 +259,6 @@ jobs:
fail-fast: false
matrix:
vector:
- - jobname: linux-sha256
- cc: clang
- pool: ubuntu-latest
- - jobname: linux-reftable
- cc: clang
- pool: ubuntu-latest
- - jobname: linux-gcc
- cc: gcc
- cc_package: gcc-8
- pool: ubuntu-20.04
- - jobname: linux-TEST-vars
- cc: gcc
- cc_package: gcc-8
- pool: ubuntu-20.04
- jobname: osx-clang
cc: clang
pool: macos-13
@@ -285,21 +271,6 @@ jobs:
- jobname: osx-meson
cc: clang
pool: macos-13
- - jobname: linux-gcc-default
- cc: gcc
- pool: ubuntu-latest
- - jobname: linux-leaks
- cc: gcc
- pool: ubuntu-latest
- - jobname: linux-reftable-leaks
- cc: gcc
- pool: ubuntu-latest
- - jobname: linux-asan-ubsan
- cc: clang
- pool: ubuntu-latest
- - jobname: linux-meson
- cc: gcc
- pool: ubuntu-latest
env:
CC: ${{matrix.vector.cc}}
CC_PACKAGE: ${{matrix.vector.cc_package}}
@@ -342,6 +313,44 @@ jobs:
fail-fast: false
matrix:
vector:
+ - jobname: linux-sha256
+ image: ubuntu:latest
+ cc: clang
+ distro: ubuntu-latest
+ - jobname: linux-reftable
+ image: ubuntu:latest
+ cc: clang
+ distro: ubuntu-latest
+ - jobname: linux-gcc
+ image: ubuntu:20.04
+ cc: gcc
+ cc_package: gcc-8
+ distro: ubuntu-20.04
+ - jobname: linux-TEST-vars
+ image: ubuntu:20.04
+ cc: gcc
+ cc_package: gcc-8
+ distro: ubuntu-20.04
+ - jobname: linux-gcc-default
+ image: ubuntu:latest
+ cc: gcc
+ distro: ubuntu-latest
+ - jobname: linux-leaks
+ image: ubuntu:latest
+ cc: gcc
+ distro: ubuntu-latest
+ - jobname: linux-reftable-leaks
+ image: ubuntu:latest
+ cc: gcc
+ distro: ubuntu-latest
+ - jobname: linux-asan-ubsan
+ image: ubuntu:latest
+ cc: clang
+ distro: ubuntu-latest
+ - jobname: linux-meson
+ image: ubuntu:latest
+ cc: gcc
+ distro: ubuntu-latest
- jobname: linux-musl
image: alpine
distro: alpine-latest
@@ -363,6 +372,7 @@ jobs:
env:
jobname: ${{matrix.vector.jobname}}
distro: ${{matrix.vector.distro}}
+ CC: ${{matrix.vector.cc}}
runs-on: ubuntu-latest
container: ${{matrix.vector.image}}
steps:
We have split the CI jobs in GitHub Workflows into two categories: - Those running on a machine pool directly. - Those running in a container on the machine pool. The latter is more flexible because it allows us to freely pick whatever container image we want to use for a specific job, while the former only allows us to pick from a handful of different distros. The containerized jobs do not have any significant downsides to the best of my knowledge: - They aren't significantly slower to start up. A quick comparison by Peff shows that the difference is mostly lost in the noise: job | old | new --------------------|------|------ linux-TEST-vars 11m30s 10m54s linux-asan-ubsan 30m26s 31m14s linux-gcc 9m47s 10m6s linux-gcc-default 9m47s 9m41s linux-leaks 25m50s 25m21s linux-meson 10m36s 10m41s linux-reftable 10m25s 10m23s linux-reftable-leaks 27m18s 27m28s linux-sha256 9m54s 10m31s Some jobs are a bit faster, some are a bit slower, but there does not seem to be any significant change. - Containerized jobs run as root, which keeps a couple of tests from running. This has been addressed in the preceding commit though, where we now use setpriv(1) to run tests as a separate user. - GitHub injects a Node binary into containerized jobs, which is dynamically linked. This has led to some issues in the past [1], but only for our 32 bit jobs. The issues have since been resolved. Overall there seem to be no downsides, but the upside is that we have more control over the exact image that these jobs use. Convert the Linux jobs accordingly. [1]: https://lore.kernel.org/git/20240912094841.GD589828@coredump.intra.peff.net/ Signed-off-by: Patrick Steinhardt <ps@pks.im> --- .github/workflows/main.yml | 68 ++++++++++++++++++++++++++-------------------- 1 file changed, 39 insertions(+), 29 deletions(-)