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

From: Philip <philip.c.peterson@gmail.com>
Date: May 26, 2024, 06:34 UTC
Message-ID: <CAJ6X7_VSswj6pw2gyfEp=Hmx237MJEJA4bW+QkKNs88iRf=Hwg@mail.gmail.com>
In-Reply-To: <Zkc_zJGjwg0fZkRG@tanuki>

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:

Show 63 quoted lines

>
> 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();
>
>  cleanup: