[libc++] Fix the Docker image build #150679
Conversation
As a drive-by, also fix a comment that was outdated.
llvmbot
added
the
libc++
|
Note that for now, this doesn't fix anything cause I still haven't figured out the issue. |
|
@llvm/pr-subscribers-libcxx Author: Louis Dionne (ldionne) ChangesAs a drive-by, also fix a comment that was outdated. Full diff: https://github.com/llvm/llvm-project/pull/150679.diff 1 Files Affected:
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
|
There was a problem hiding this comment.
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.
|
@boomanaiden154 Thanks for the comment. I opened this with the good intent of spending some time on it but ended up never having time to do it. I'll close this since it seems to be working now, see #154856. |
As a drive-by, also fix a comment that was outdated.