From cba7e0d7506613b9df614085f0babeb3687bdf2f Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Tue, 24 Sep 2024 08:47:39 +0200 Subject: [PATCH 1/2] ci: work around a problem with HTTP/2 vs libcurl v8.10.0 As reported in https://lore.kernel.org/git/ZuPKvYP9ZZ2mhb4m@pks.im/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at https://github.com/git-for-windows/git/issues/5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin --- t/t5551-http-fetch-smart.sh | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh index 7b5ab0eae16012..85fd0a197d0356 100755 --- a/t/t5551-http-fetch-smart.sh +++ b/t/t5551-http-fetch-smart.sh @@ -381,7 +381,15 @@ test_expect_success CMDLINE_LIMIT \ ) ' -test_expect_success 'large fetch-pack requests can be sent using chunked encoding' ' +# This is a temporary work-around for libcurl v8.10.0 on the macos-* runners; +# see https://github.com/git-for-windows/git/issues/5159 for full details +test_lazy_prereq UNBROKEN_HTTP2 ' + test "$HTTP_PROTO" = HTTP/2 && + test -z "$(brew info -q curl 2>/dev/null | + sed -n "/^Installed/{N;s/.*8\\.10\\.0.*/BROKEN HTTP2/p;}")" +' + +test_expect_success UNBROKEN_HTTP2 'large fetch-pack requests can be sent using chunked encoding' ' GIT_TRACE_CURL=true git -c http.postbuffer=65536 \ clone --bare "$HTTPD_URL/smart/repo.git" split.git 2>err && { From 42b42256ca4fa284f90f3dea9b256074daeb916a Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 13 Sep 2024 12:26:41 -0700 Subject: [PATCH 2/2] t5512.40 sometimes dies by SIGPIPE The last test in t5512 we recently added seems to be flaky. Running $ make && cd t && sh ./t5512-ls-remote.sh --stress shows that "git ls-remote foo::bar" exited with status 141, which means we got a SIGPIPE. This test piece was introduced by 9e89dcb6 (builtin/ls-remote: fall back to SHA1 outside of a repo, 2024-08-02) and is pretty much independent from all other tests in the script (it can even run standalone with everything before it removed). The transport-helper.c:get_helper() function tries to write to the helper. As we can see the helper script is very short and can exit even before it reads anything, when get_helper() tries to give the first command, "capabilities", the helper may already be gone. A trivial fix, presented here, is to make sure that the helper reads the first command it is given, as what it writes later is a response to that command. I however would wonder if the interactions with the helper initiated by get_helper() should be done on a non-blocking I/O (we do check the return value from our write(2) system calls, do we?). Backported-from: e1e0d305c41 (t5512.40 sometimes dies by SIGPIPE, 2024-09-13) Signed-off-by: Junio C Hamano Signed-off-by: Johannes Schindelin --- t/t5512-ls-remote.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh index bc442ec221da93..3a67992a7dc086 100755 --- a/t/t5512-ls-remote.sh +++ b/t/t5512-ls-remote.sh @@ -405,6 +405,7 @@ test_expect_success 'v0 clients can handle multiple symrefs' ' test_expect_success 'helper with refspec capability fails gracefully' ' mkdir test-bin && write_script test-bin/git-remote-foo <<-EOF && + read capabilities echo import echo refspec ${SQ}*:*${SQ} EOF