Change:
kube::golang::build_some_binaries "${nonstatics[@]}" fi <ins> # Workaround for https://github.com/kubernetes/kubernetes/issues/115675 local testgogcflags="${gogcflags}" local testgoexperiment="${GOEXPERIMENT:-}" if [[ "$(go version)" == *"go1.20"* && "${platform}" == "linux/arm" ]]; then # work around https://github.com/golang/go/issues/58339 until fixed in go1.20.x testgogcflags="${testgogcflags} -d=inlstaticinit=0" # work around https://github.com/golang/go/issues/58425 testgoexperiment="nounified,${testgoexperiment}" kube::log::info "Building test binaries with GOEXPERIMENT=${testgoexperiment} GCFLAGS=${testgogcflags} ASMFLAGS=${goasmflags} LDFLAGS=${goldflags}" fi </ins> for test in "${tests[@]:+${tests[@]}}"; do local outfile testpkg outfile=$(kube::golang::outfile_for_binary "${test}" "${platform}") testpkg=$(dirname "${test}") mkdir -p "$(dirname "${outfile}")" <del> go test -c  </del> <ins> GOEXPERIMENT="${testgoexperiment}" go test -c  </ins> ${goflags:+"${goflags[@]}"}  <del> -gcflags="${gogcflags}"  </del> <ins> -gcflags="${testgogcflags}"  </ins> -asmflags="${goasmflags}"  -ldflags="${goldflags}"  -tags="${gotags:-}" 

Discussion:
master-blocking build-master Overall build is failing ! 2023-02-09 23:09:58 +0000 UTC make: [Makefile:487: cross] Error 1 !!! [0210 00:35:55] Call tree: !!! [0210 00:35:55] 1: kube::build::runbuildcommandex(...) !!! [0210 00:35:55] 2: kube::build::runbuildcommand(...) make: [Makefile:374: release] Error 1 level=fatal msg="failed to run: running make release: command /usr/bin/make release did not succeed: !!! [0210 00:35:54] Call tree:n!!! [0210 00:35:54] 1: hack/make- kube::golang::buildbinaries(...)nmake[1]: [Makefile:92: all] Error 1nmake: [Makefile:487: cross] Error 1n!!! [0210 00:35:55] Call tree:n!!! [0210 00:35:55] 1: kube::build::runbuildcommandex(...)n!!! [0210 00:35:55] 2: kube::build::runbuildcommand(...)nmake: * [Makefile:374: release] Error 1n" No response_ /sig testing
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/priority critical-urgent
looks like the same issue again: /cc
This would fall under sig-release or sig-testing? couldn't really gather much from logs about this though failure is so I guess sig-release then.
I'm going to reopen for that, which should work around the issue.
that's correct :) /remove-sig testing /sig release
The PR does not seem to fix the problem without disabling test cases. Opening a slack discussion and closing the loop:
Failing again.

/reopen
Reopened this issue. <detailsIn response to : Failing again. /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
this is a different error: can we spawn a new issue to track rather than reopening the same one and mixing investigations for different issues?
Oh just the stack trace for make was the same, my bad, opened /close
Closing this issue. <detailsIn response to : Oh just the stack trace for make was the same, my bad, opened Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details