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

Philip
2024-05-26T06:34:42Z

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.

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"

Cheers,
Phil

On Fri, May 17, 2024 at 7:30 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Fri, May 17, 2024 at 10:25:20AM +0200, Patrick Steinhardt wrote:
> > On Fri, May 17, 2024 at 04:11:32AM -0400, Jeff King wrote:
> > > On Thu, May 16, 2024 at 02:36:19PM +0200, Patrick Steinhardt wrote:
> > [snip]
> > > One can guess that scalar is in waitpid() waiting for git-fetch. But
> > > what's fetch waiting on? The other side of upload-pack is dead.
> > > According to lsof, it does have a unix socket open to fsmonitor. So
> > > maybe it's trying to read there?
> >
> > That was also my guess. I tried whether disabling fsmonitor via
> > `core.fsmonitor=false` helps, but that did not seem to be the case.
> > Either because it didn't have the desired effect, or because the root
> > cause is not fsmonitor. No idea which of both it is.
>
> The root cause actually is the fsmonitor. I was using your tmate hack to
> SSH into one of the failed jobs, and there had been 7 instances of the
> fsmonitor lurking. After killing all of them the job got unstuck and ran
> to completion.
>
> The reason why setting `core.fsmonitor=false` is ineffective is because
> in "scalar.c" we always configure `core.fsmonitor=true` in the repo
> config and thus override the setting. I was checking whether it would
> make sense to defer enabling the fsmonitor until after the fetch and
> checkout have concluded. But funny enough, the below patch caused the
> pipeline to now hang deterministically.
>
> Puzzled.
>
> Patrick
>
> diff --git a/scalar.c b/scalar.c
> index 7234049a1b..67f85c7adc 100644
> --- a/scalar.c
> +++ b/scalar.c
> @@ -178,13 +178,6 @@ static int set_recommended_config(int reconfigure)
> config[i].key, config[i].value);
> }
>
> - if (have_fsmonitor_support()) {
> - struct scalar_config fsmonitor = { "core.fsmonitor", "true" };
> - if (set_scalar_config(&fsmonitor, reconfigure))
> - return error(_("could not configure %s=%s"),
> - fsmonitor.key, fsmonitor.value);
> - }
> -
> /*
> * The `log.excludeDecoration` setting is special because it allows
> * for multiple values.
> @@ -539,6 +532,13 @@ static int cmd_clone(int argc, const char **argv)
> if (res)
> goto cleanup;
>
> + if (have_fsmonitor_support()) {
> + struct scalar_config fsmonitor = { "core.fsmonitor", "true" };
> + if (set_scalar_config(&fsmonitor, 0))
> + return error(_("could not configure %s=%s"),
> + fsmonitor.key, fsmonitor.value);
> + }
> +
> res = register_dir();
>