public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Philip <philip.c.peterson@gmail.com>, Jeff King <peff@peff.net>,
	git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>,
	Jeff Hostetler <jeffhostetler@github.com>
Subject: Re: [PATCH 3/3] ci: stop installing "gcc-13" for osx-gcc
Date: Mon, 27 May 2024 07:12:13 +0200	[thread overview]
Message-ID: <ZlQWLeLFrkZszciM@tanuki> (raw)
In-Reply-To: <xmqqr0doe5sp.fsf@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

On Sun, May 26, 2024 at 12:23:18PM -0700, Junio C Hamano wrote:
> 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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-05-27  5:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-09 16:22 [PATCH 0/3] un-breaking osx-gcc ci job Jeff King
2024-05-09 16:23 ` [PATCH 1/3] ci: drop mention of BREW_INSTALL_PACKAGES variable Jeff King
2024-05-09 16:24 ` [PATCH 2/3] ci: avoid bare "gcc" for osx-gcc job Jeff King
2024-05-10  7:00   ` Patrick Steinhardt
2024-05-10 20:16     ` Jeff King
2024-05-10 20:32   ` Kyle Lippincott
2024-05-10 20:48     ` Junio C Hamano
2024-05-10 22:02     ` Jeff King
2024-05-10 22:47       ` Junio C Hamano
2024-05-11 17:21         ` Patrick Steinhardt
2024-05-16  7:19           ` Jeff King
2024-05-16  7:27             ` Jeff King
2024-05-16  9:54             ` Patrick Steinhardt
2024-05-17  8:19               ` Jeff King
2024-05-17  8:33                 ` Patrick Steinhardt
2024-05-17 16:59                 ` Junio C Hamano
2024-05-23  9:10                   ` Jeff King
2024-05-23 15:35                     ` Junio C Hamano
2024-05-09 16:25 ` [PATCH 3/3] ci: stop installing "gcc-13" for osx-gcc Jeff King
2024-05-10  7:00   ` Patrick Steinhardt
2024-05-10 20:13     ` Jeff King
2024-05-11  7:17       ` Patrick Steinhardt
2024-05-16 12:36         ` Patrick Steinhardt
2024-05-17  8:11           ` Jeff King
2024-05-17  8:25             ` Patrick Steinhardt
2024-05-17 11:30               ` Patrick Steinhardt
2024-05-26  6:34                 ` Philip
2024-05-26 19:23                   ` Junio C Hamano
2024-05-27  5:12                     ` Patrick Steinhardt [this message]
2024-05-29  9:27                   ` Jeff King
2024-05-09 16:52 ` [PATCH 0/3] un-breaking osx-gcc ci job Junio C Hamano

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=ZlQWLeLFrkZszciM@tanuki \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jeffhostetler@github.com \
    --cc=peff@peff.net \
    --cc=philip.c.peterson@gmail.com \
    --cc=stolee@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox