[libcxx] Bump Container Runner Version

[boomanaiden154]

This patch bumps the runner version from v3.222.0 to v3.226.0 as v3.222.0 is too old at this point to connect to Github. This is needed for the new premerge system given we are directly using this container. This did not impact the existing libc++ CI as the runner was contained in a separate container image.

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: Aiden Grossman (boomanaiden154)

Changes

This patch bumps the runner version from v3.222.0 to v3.226.0 as v3.222.0 is too old at this point to connect to Github. This is needed for the new premerge system given we are directly using this container. This did not impact the existing libc++ CI as the runner was contained in a separate container image.

---

Full diff: https://github.com/llvm/llvm-project/pull/147831.diff

1 Files Affected:

• (modified) libcxx/utils/ci/docker-compose.yml (+1-1)

diff --git a/libcxx/utils/ci/docker-compose.yml b/libcxx/utils/ci/docker-compose.yml
index 9aa58c055cea1..2189a41555c2f 100644
--- a/libcxx/utils/ci/docker-compose.yml
+++ b/libcxx/utils/ci/docker-compose.yml
@@ -10,7 +10,7 @@ services:
       dockerfile: Dockerfile
       target: actions-builder
       args:
-        BASE_IMAGE: ghcr.io/actions/actions-runner:2.322.0
+        BASE_IMAGE: ghcr.io/actions/actions-runner:2.326.0
         <<: *compiler_versions
 
   android-buildkite-builder:

[EricWF]

This did not impact the existing libc++ CI as the runner was contained in a separate container image.

FWIW, This was the main reason why we moved to using a separate container image; We weren't proactive in upgrading the runner versions, and it caused multiple CI outages.

[boomanaiden154]

FWIW, This was the reason why we moved to using a separate container image; We weren't proactive in upgrading the runner versions, and it caused multiple CI outages.

Yeah, I'm realizing now why it's hard to build your CI image in such a way that it's reproducible with all the ToT compilers. What we've done for the current premerge is installed the runner version at the end rather than using the actions/runner base image. We also did this as a multi-stage build. That allows for changing the runner version without changing anything else will still using a single container.

[EricWF]

Should we maybe just use "latest" here?

I don't feel too strongly one way or the other. One approach makes the container build more deterministic but the other requires less maintenance.

[boomanaiden154]

I'd prefer to keep the version pinned just for reproducibility. I'll probably change how this is wired up at some point too to make upgrading the runner version less of a pain (so that we only touch the runner and not everything else).

[boomanaiden154]

I also tried an image built locally with this config and it looks like one of the stage one builds is failing with ToT clang. For now I've pushed llvm/llvm-zorg@817d047 which uses a container version based on the current one used with just the runner version upgraded produced with the following script:

FROM ghcr.io/llvm/libcxx-linux-builder:b060022103f551d8ca1dad84122ef73927c86512
RUN rm -rf ./*
ENV GITHUB_RUNNER_VERSION=2.326.0
RUN curl -O -L https://github.com/actions/runner/releases/download/v$GITHUB_RUNNER_VERSION/actions-runner-linux-x64-$GITHUB_RUNNER_VERSION.tar.gz && \
    tar xzf ./actions-runner-linux-x64-$GITHUB_RUNNER_VERSION.tar.gz && \
    rm ./actions-runner-linux-x64-$GITHUB_RUNNER_VERSION.tar.gz

This change still is needed for the next time the container gets bumped though.