Over the past few days, I've submitted several merge requests from
branches on my forked project (mostly because I didn't even realize
pushing to a branch on the main project was an alternative).
When those MRs run under CI, I've had a bunch of failures due to
timeouts waiting on a darwin-x86_64 runner. I was a little mystified
that no other pipelines besides mine seemed to be having this problem,
but I've come to understand that MRs submitted from branches on the main
project use a different, larger set of runners than the shared runners
used by MRs from branches on forked projects.
Under my project, I can view the available shared runners under the
"Settings" -> "CI/CD" -> "Runners" tab, and the problem seems to be that
there's only one darwin runner ("b4bc6410" /
mac-mini-x86_64-darwin-davxkc). This machine is a trooper, but it
unfortunately shares a circuit breaker with a toaster oven, so it goes
offline every time someone wants a bagel, and the rest of the time it
must be running CI for a few hundred GHC forks.
I ended up deleting an (unreviewed) MR sourced from my branch, and
pushing it to the main project and resubmitting just to get the CI to
run. (Admittedly, it failed, but at least not on darwin!) I obviously
don't want to do this with the merge requests that have already been
reviewed.
Is this a temporary problem? Is there anything I can do other than keep
retrying the darwin jobs every couple days?
Also, is there a better place than "ghc-dev" to send these sorts of
GitLab/CI issues? I thought there might be a project dedicated to it,
but if so I couldn't find it.
--
Kevin Buhr <b...@asaurus.net>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
