Yeah. That’s my current theory. It doesn’t help that the queue length
isn’t visible
On Mon, May 13, 2019 at 8:43 AM Ben Gamari wrote:
> Carter Schonwald writes:
>
> > Cool. I recommend irc and devs list plus urls / copies of error
> messages.
> >
> > Hard to debug timeout if we don’t have th
Carter Schonwald writes:
> Cool. I recommend irc and devs list plus urls / copies of error messages.
>
> Hard to debug timeout if we don’t have the literal url or error messages
> shared !
>
For what it's worth I suspect these timeouts are simply due to the fact
that we are somewhat lacking in
Subject: Re: CI on forked projects: Darwin woes
Thanks! I'll send a note if it starts happening again.
On 5/12/19 7:23 AM, Carter Schonwald wrote:
>
[ . . . ]
> Next time you hit a failure could you share with the devs list and or
> #ghc irc ?
I’m the root care taker on the Mac ci box.
One issue here is that while forks and branches both get ci, only branches
are visible to non admin roles. So there could be a kajillion other folks
forks going on or something.
timeouts sound like gitlab side thing. I definitely have had to restart
jo
I think there was the ghc-devops-group list, but I don't know if it is
still active, and I kind of like to not have to follow too many lists.
For example, I had also not realized that it is an option to push to
branches on the main project, and have been using my own fork,
so thanks for posting th
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_
