Hi Ben, thanks for the explanation, that indeed makes sense. I suspected some runaway optimisation, since the GHC seemed to crash on the same small set of sources.
On a related note, even after rebasing to master, the linter of ghc/ghc!10 doesn't appear to kick in, blocking (and timing out) the test pipeline: https://gitlab.haskell.org/ggreif/ghc/pipelines/428 It looks like there are no "lint" runners available. Cheers and thanks, Gabor On 12/22/18, Ben Gamari <b...@smart-cactus.org> wrote: > Gabor Greif <ggr...@gmail.com> writes: > >> Hi Ben, >> > Hi Gabor, > >> I was wondering why my pull request (merely to trigger a bit more of >> CI than what I have at my local disposal) was suddenly failing (1), >> when it worked in a previous incarnation (2). >> >> It turns out that either CI or the entire tree is broken since (3) >> being the last sound one. >> > Indeed CircleCI recently revised their billing policies and consequently > we have lost the ability to use the large instance sizes which we were > previously using for our builds. Sadly GHC builds do not reliably finish > on the instances we still do have access to due to memory and build time > constraints. It appears that this may be the cause of the failures in > your build (1). > > This billing change was the reason why I have been moving our CI > infrastructure to GitLab. Unfortunately in the chaos it looks like I > neglected to forward the ghc-devops thread describing the situation [2] > to ghc-devs. Sorry for the confusion! > > I'm going to draft a summary email describing the state of the GitLab > transition right now. > > Cheers, > > - Ben > > > [2] > https://mail.haskell.org/pipermail/ghc-devops-group/2018-December/000273.html > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
