Re: [PATCH 3/3] ci: stop installing "gcc-13" for osx-gcc

From: Patrick Steinhardt <ps@pks.im>
Date: May 27, 2024, 05:12 UTC
Message-ID: <ZlQWLeLFrkZszciM@tanuki>
In-Reply-To: <xmqqr0doe5sp.fsf@gitster.g>

On Sun, May 26, 2024 at 12:23:18PM -0700, Junio C Hamano wrote:

Show 12 quoted lines

> Philip <philip.c.peterson@gmail.com> writes:
> 
> > Part of the problem seems to be that the Github actions runner has a bug
> > on OSX: https://github.com/actions/runner/issues/884
> >
> > Based on investigating this for a while by setting up a self-hosted actions
> > runner, it seems to have to do with a broken pipe triggering incomplete
> > output capture / termination detection by either Github Action Runner (
> > see issue thread) or maybe even Dotnet Core's
> > System.Diagnostics.Process functionality.
> 
> Thanks for digging into this.

Indeed, thanks for digging.

In any case, whatever it is, it cannot be exclusively due to a bug with GitHub given that we see the same issue happening with GitLab CI.

Show 14 quoted lines

> > As for the actual failing test, t9211, what I got on my machine was a
> > failure during clone: `unknown repository extension found: refstorage`.
> > In the trash directory, the .git/config did specify that extension.
> > Perhaps some interference coming from
> > t9500-gitweb-standalone-no-errors.sh, since it invokes:
> >
> >> git config extensions.refstorage "$refstorage"
> 
> Puzzled.  We run t9211 in "t/trash directory.t9211-whatever/"
> directory with its own repository, so that what t9500 does in its
> own playpen, "t/trash directory.t9500-gitweb-standalone-no-errors/"
> directory would not interfere with it to begin with.  How would that
> setting seep through to an unrelated test run next door?  It's not
> like they share TCP port number or anything like that?

This error looks somewhat weird to me. Why should anything part of Git not recognize the refstorage extension? It almost feels as if there were different versions of Git being used.

I'm quite positive by now that the error is somewhere in the fsmonitor. I was double checking whether there is an issue with reuse of some of its sockets across test suites. But given that the tests have different HOMEs and that they have different repository paths, I couldn't really find anything that might be reused across invocations of scalar(1) or the git-fsmonitor--daemon(1).

Patrtick