Re: [PATCH] t5410: avoid hangs in CI runs in the win+Meson test jobs

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 5, 2025, 13:30 UTC
Message-ID: <xmqqseke9uzk.fsf@gitster.g>
In-Reply-To: <pull.1932.git.1749118606047.gitgitgadget@gmail.com>

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 16 quoted lines

> ...
> 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.

Show 10 quoted lines

> +# 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.