ci: work around a problem with HTTP/2 vs libcurl v8.10.0 #5165
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 git-for-windows#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 <johannes.schindelin@gmx.de>
dscho
force-pushed
the
work-around-curl-8.10.0-vs-http2
branch
from
6d3ab73
to
cba7e0d
Compare
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 9e89dcb
(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: e1e0d30 (t5512.40 sometimes dies by SIGPIPE, 2024-09-13)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 24, 2024
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The `macos-13` runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case. While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully"). This fixes #5159.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 24, 2024
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The `macos-13` runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case. While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully"). This fixes #5159.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 24, 2024
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The `macos-13` runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case. While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully"). This fixes #5159.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 24, 2024
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The `macos-13` runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case. While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully"). This fixes #5159.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The
macos-13runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case.While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully").
This fixes #5159.