| Message ID | 20250103-b4-pks-ci-fixes-v1-4-a9bb95dff833@pks.im (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | A couple of CI improvements | expand |
On Fri, Jan 03, 2025 at 03:46:41PM +0100, Patrick Steinhardt wrote: > 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 shouldn't cause a significant slowdown, either, so they do not have > any significant upside to the best of my knowlegde. The only upside that > they did have before the preceding commit is that they run as a non-root > user, but that has been addressed now. I remember running into a few issues recently with containerized jobs, so I dug in the archive a bit. The issue there was that the container was not equipped to support the dynamically-linked version of node that was being mounted into place (whereas the runner image from the CI provider would work fine). I guess that's probably not a big deal for us here. These are roughly the same environments, just pulling from docker instead of relying on the runner images. It's possible that Actions scripts might depend on something special in the runner image, but in practice I think they try to keep the dependencies pretty light. So we're probably OK to proceed here, and deal with any problems in the unlikely event that they come up. I do wonder if it will affect run times. Presumably GitHub has made it pretty fast to get things started on the bare runner image. Now we're pulling docker images. That is hopefully pretty optimized and cached, but it is extra work. Might be worth measuring. -Peff
On Fri, Jan 03, 2025 at 01:56:40PM -0500, Jeff King wrote: > I do wonder if it will affect run times. Presumably GitHub has made it > pretty fast to get things started on the bare runner image. Now we're > pulling docker images. That is hopefully pretty optimized and cached, > but it is extra work. Might be worth measuring. Just peeking at your CI run here: https://github.com/git/git/actions/runs/12597967146 versus the latest run on Junio's master: https://github.com/git/git/actions/runs/12589300693 I see: 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 So it looks like any change is lost in the noise (sha256 is noticeably slower, but most jobs aren't, and some are even faster). -Peff
Patrick Steinhardt <ps@pks.im> writes: > ... The containerized > jobs shouldn't cause a significant slowdown, either, so they do not have > any significant upside to the best of my knowlegde. "shouldn't" is a somewhat hand-wavy word. "knowlegde" -> "knowledge". Are there security implications for us to worry about? How tightly are these container images controlled, relative to the way forges prepare their selected environments? Thanks.
On Fri, Jan 03, 2025 at 02:06:59PM -0500, Jeff King wrote: > On Fri, Jan 03, 2025 at 01:56:40PM -0500, Jeff King wrote: > > > I do wonder if it will affect run times. Presumably GitHub has made it > > pretty fast to get things started on the bare runner image. Now we're > > pulling docker images. That is hopefully pretty optimized and cached, > > but it is extra work. Might be worth measuring. > > Just peeking at your CI run here: > > https://github.com/git/git/actions/runs/12597967146 > > versus the latest run on Junio's master: > > https://github.com/git/git/actions/runs/12589300693 > > I see: > > 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 > > So it looks like any change is lost in the noise (sha256 is noticeably > slower, but most jobs aren't, and some are even faster). Thanks for verifying my claims! Patrick
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index b02f5873a540b458d38e7951b4ee3d5ca598ae23..8e5847da4fab009ad699c18e1a5a336a8b45c3ed 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -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 shouldn't cause a significant slowdown, either, so they do not have any significant upside to the best of my knowlegde. The only upside that they did have before the preceding commit is that they run as a non-root user, but that has been addressed now. Convert all Linux jobs to be containerized for additional flexibility. Signed-off-by: Patrick Steinhardt <ps@pks.im> --- .github/workflows/main.yml | 68 ++++++++++++++++++++++++++-------------------- 1 file changed, 39 insertions(+), 29 deletions(-)