On Fri, May 10, 2024 at 04:13:48PM -0400, Jeff King wrote: > On Fri, May 10, 2024 at 09:00:04AM +0200, Patrick Steinhardt wrote: > > > On Thu, May 09, 2024 at 12:25:44PM -0400, Jeff King wrote: > > [snip] > > > I'd like to report that this let me get a successful CI run, but I'm > > > running into the thing where osx jobs seem to randomly hang sometimes > > > and hit the 6-hour timeout. But I did confirm that this lets us get to > > > the actual build/test, and not barf while installing dependencies. > > > > Yeah, this one is puzzling to me. We see the same thing on GitLab CI, > > and until now I haven't yet figured out why that is. > > Drat. I was hoping maybe it was a problem in GitHub CI and somebody else > would eventually fix it. ;) > > It feels like a deadlock somewhere, though whether it is in our code, or > in our tests, or some system-ish issue with prove, perl, etc, I don't > know. It would be nice to catch it in the act and see what the process > tree looks like. I guess poking around in the test environment with > tmate might work, though I don't know if there's a way to get tmate > running simultaneously with the hung step (so you'd probably have to > connect, kick off the "make test" manually and hope it hangs). My hunch tells me that it's the Perforce tests -- after all, this is where the jobs get stuck, too. In "lib-git-p4.sh" we already document that p4d is known to crash at times, and overall the logic to spawn the server is quite convoluted. I did try to get more useful logs yesterday. But as usual, once you _want_ to reproduce a failure like this is doesn't happen anymore. > > > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > > > index 5f92a50271..13cc0fe807 100644 > > > --- a/.github/workflows/main.yml > > > +++ b/.github/workflows/main.yml > > > @@ -285,7 +285,6 @@ jobs: > > > pool: macos-13 > > > - jobname: osx-gcc > > > cc: gcc-13 > > > - cc_package: gcc-13 > > > > As far as I can see this means that we don't install GCC at all anymore > > via Homebrew. Does this mean that we now rely on the GCC version that is > > preinstalled by Homebrew? Won't this break every time that Homebrew > > changes the default GCC version? > > > > I may be missing the obvious. > > Yes, we'll have to update to a different version when the runner image > stops carrying gcc-13. But it's not based on homebrew's default. > According to: > > https://github.com/actions/runner-images/blob/macos-13/20240506.1/images/macos/macos-13-Readme.md > > the runner image contains gcc-11, gcc-12, and gcc-13. So presumably it > would be a while before gcc-13 ages out and we have to bother bumping. I > do agree it would be nice to just use the latest gcc in the image, but I > don't think we can specify that here. I guess we could say "gcc-auto" or > something, and then the actual shell code could poke around for it. Ah, thanks for the explanation. I was worried that things might break at arbitrary points in time. But if this is only containde to whenever we upgrade the runner image, then I don't see this as much of a problem. Patrick
Attachment:
signature.asc
Description: PGP signature
