From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] t5410: avoid hangs in CI runs in the win+Meson test jobs
Date: Thu, 05 Jun 2025 06:30:07 -0700 [thread overview]
Message-ID: <xmqqseke9uzk.fsf@gitster.g> (raw)
In-Reply-To: <pull.1932.git.1749118606047.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Thu, 05 Jun 2025 10:16:45 +0000")
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> ...
> This bug in the MSYS2 runtime has been fixed in the meantime, which is
> the reason why the same test case causes no problems in the `win test`
> and the `vs test` jobs.
>
> This will continue to be the case until the Git for Windows version on
> the GitHub runners is upgraded to a version that distributes a newer
> MSYS2 runtime version. However, as of time of writing, this _is_ the
> latest Git for Windows version, and will be for another 1.5 weeks, until
> Git v2.50.0 is scheduled to appear (and shortly thereafter Git for
> Windows v2.50.0). Traditionally it takes a while before the runners pick
> up the new version.
> ...
> I finally had a chance to look more closely at this problem. Here is my
> alternative to what Patrick proposed in
> https://lore.kernel.org/git/aD7tKfXD7YxprSZh@pks.im/.
Superb. It must have taken a truly heroic effort.
Thanks and congratulations for finally solving the puzzle.
I do agree that Patrick's "wrap the same in a script" smelled like
shifting a timing issue and not truly a solution.
> +# The `tee.exe` shipped in Git for Windows v2.49.0 is known to hang frequently
> +# when spawned from `git.exe` and piping its output to `git.exe`. This seems
> +# related to MSYS2 runtime bug fixes regarding the signal handling; Let's just
> +# skip the tests that need to exercise this when the faulty MSYS2 runtime is
> +# detected; The test cases are exercised enough in other matrix jobs of the CI
> +# runs.
> +test_lazy_prereq TEE_DOES_NOT_HANG '
> + test_have_prereq !MINGW &&
> + case "$(uname -a)" in *3.5.7-463ebcdc.x86_64*) false;; esac
> +'
That's very specific ;-).
As this is not in a library-ish part, it does not have to be lazy.
Anybody running this test script need to tell if their environment
satisfies the prerequisite, but lazy one does have a documentation
value, I guess, and a bit of extra indirection does not hurt.
Will queue. Thanks again.
prev parent reply other threads:[~2025-06-05 13:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 10:16 [PATCH] t5410: avoid hangs in CI runs in the win+Meson test jobs Johannes Schindelin via GitGitGadget
2025-06-05 11:10 ` Patrick Steinhardt
2025-06-05 13:30 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqseke9uzk.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johannes.schindelin@gmx.de \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.