[libc++] Fix the Docker image build

[ldionne]

As a drive-by, also fix a comment that was outdated.

[ldionne]

Note that for now, this doesn't fix anything cause I still haven't figured out the issue.

[ldionne]

CC @boomanaiden154

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: Louis Dionne (ldionne)

Changes

As a drive-by, also fix a comment that was outdated.

---

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

1 Files Affected:

• (modified) libcxx/utils/ci/Dockerfile (+2-3)

diff --git a/libcxx/utils/ci/Dockerfile b/libcxx/utils/ci/Dockerfile
index 63ceceaa67635..036552aa27ffa 100644
--- a/libcxx/utils/ci/Dockerfile
+++ b/libcxx/utils/ci/Dockerfile
@@ -46,9 +46,8 @@ FROM $BASE_IMAGE AS builder-base
 
 # Changing this file causes a rebuild of the image in a GitHub action.
 # However, it does not cause the CI runners to switch to that image
-# automatically, that must be done by updating the SHA in the Github workflow
-# file. The date uses the ISO format YYYY-MM-DD.
-RUN echo "Last forced update executed on 2025-04-28."
+# automatically, to do that please refer to the documentation.
+RUN echo "Last forced update executed on 2025-07-25."
 
 # Make sure apt-get doesn't try to prompt for stuff like our time zone, etc.
 ENV DEBIAN_FRONTEND=noninteractive

[boomanaiden154]

Are you looking at updating the image currently? These changes seem reasonable enough to me, but not exactly sure what the goal is.

I was going to look into it soonish after the dust settled around the 22 branch and apt.llvm.org started working again. I was hoping to get #148072 and #148073 landed first though before I started looking at that so we could enable the workflow to update the runner separately.

I was hoping to do an iteration or two to get the new workflow primed, although I'm hoping someone in libc++ can own the image updating more permanently (if this isn't already the case).

As an update on trying to move back to specifying images in the jobs, we met with a GKE engineer about the issue. Our hunch was correct and it is a konnectivity related issue. We should be able to work around it if we can get konnectivity pods to not schedule on the autoscaling node pools, but the autoscaler for konnectivity pods ignores taints and I haven't had time to look into how/if we can configure it to do what we want. So, slow progress but we're not there yet.