Change:
function kube::util::ensure-gnu-sed { # NOTE: the echo below is a workaround to ensure sed is executed before the grep. # see: https://github.com/kubernetes/kubernetes/issues/87251 <del> if LANG=C sed --help 2>&1 | grep -q "GNU|BusyBox"; then </del> <ins> sed_help="$(LANG=C sed --help 2>&1 || true)" if echo "${sed_help}" | grep -q "GNU|BusyBox"; then </ins> SED="sed" elif command -v gsed &>/dev/null; then SED="gsed"

Discussion:
/sig release cc filing this to track before I forget in this wall of meetings .the push-all target appears to have broken shell currently which means it's probably not only broken in CI but locally ...
Hi. I've commented on slack about this, so reposting here: Looking at [1], it looks like that function was not defined. folder, I'm not getting that error. [1]
Got it. Basically, that function is called when image used by the Image Promoter, it's busybox: TLDR: So, because the image is based on busybox, function. Thoughts?
maybe we should use a different image? we check for gnu sed because of compatibility issues?
Looking through the commit history, there are only 4 cases in which the GNU sed thing was mentioned / ensured, and the reason was pretty much so the scripts can run on Mac. From what I've read online, Macs have the FreeBSD version of sed, which behaves a bit differently. only uses sed to replace a few strings in some Dockerfile files, which is pretty standard, so I don't think the busybox version would have issues with that. Will check. I am currently trying to build the images inside the aforementioned container image above, and hit another issue after the sed thing. container: docker run --rm -it -v "{TARGET}:Z" -v "${KUBEROOT}" golang:"${GOLANGVERSION}"  /bin/bash -c " cd ${SRCDIR} &amp;&amp;  CGOENABLED=0 {ARCH} go build -a -installsuffix cgo --ldflags '-w' -o {SRC} ./{SRC}")" so the Image Promoter should also be able to build containers, but considering that docker CLI is already available inside the image, I think that'll be fine. Other than that, it also tries to mount the folder inside the new container (let's call it N) (which is probably already mounted inside the builder container (let's call it A)). But I'm having issues with that, the new container N doesn't see any file in the mounted volume. I'm looking into it, but if you have any ideas, that would be helpful.
cc WDYT re: not requiring GNU sed specifically?

Update: I can currently build and push images from inside the container, which is the same one used by the promoter. I've used the following command: docker run -t --privileged -v  -v /workspace/kubernetes/:/workspace/kubernetes  -v  --entrypoint bash  -c "cd kubernetes/test/images &amp;&amp;  make all-push WHAT=all-conformance REGISTRY=claudiubelu" build-logs This was done using this PR: However, there are a few catches here, of which I'm not sure they're being done in the Image Promoter: of all, the container must be able to build and run other contaienrs, which is why the was set. . Now, docker will always mount the folder / volume from the original host, and not from the current container's files and folders. has to run as, this is needed by the multiarch builds. This might already be set in the Image Promoter, but I'm not sure. I'd like to hear some answers about 2 and 3. PS: Also, there's another thing that's puzzling me, and it;s a being weird. There's a flake when running `. That function's code is: function kube::util::ensure-gnu-sed { if LANG=C sed --help 2&1 BusyBox"; then SED="sed" elif command -v gsed &/dev/null; then SED="gsed" else kube::log::error "Failed to find GNU sed as sed or gsed. If you are on Mac: brew install gnu-sed." &2 return 1 fi kube::util::sourcedvariable "${SED}" } But, sometimes, when running it, it runs the commands out of order: ++ kube::util::ensure-gnu-sed ++ grep -q 'GNU|BusyBox' ++ LANG=C ++ sed --help ++ command -v gsed ++ kube::log::error 'Failed to find GNU sed as sed or gsed. If you are on Mac: brew install gnu-sed.' And sometimes not: ++ kube::util::ensure-gnu-sed ++ LANG=C ++ sed --help ++ grep -q 'GNU|BusyBox' ++ SED=sed ++ kube::util::sourcedvariable sed ++ true
Addressed the last issue as well.

Seems to be fine now, didn't encounter that flake anymore, and I've rebuilt all the conformance images 5-6 times already. Please review the PR, and let's try to find some answers to the points I've raised above.