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). > > 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. -Peff