
Hi Ben,
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.
Looks like x86-64 is affected on the linux platform only. Darwin seems
to work, i386 too, and my PR (2) has been validated for PPC64le
recently.
So this is just a heads up that there is something fishy with
github->CircleCI (at least).
Cheers,
Gabor
(1) https://circleci.com/gh/ghc/ghc/tree/pull/242
(2) https://circleci.com/gh/ghc/ghc/tree/pull/224
(3) https://circleci.com/gh/ghc/ghc/tree/pull/239
On 12/21/18, Ben Gamari
Ara Adkins
writes: Hey All,
Sorry for my confusion, but I'm a bit unclear as to when we're meant to start working against the GHC repo on the gitlab.haskell.org instance. I had in mind that the cutover was intended to be the 18th, but going on there it still appears as if it's mirrored from git.haskell.org. Can somebody clarify this for me?
Sorry for the confusion. I have been reluctant to formally announce the cut-over until CI is green but this has taken a fair bit longer than anticipated due to the long CI cycle time. Nevertheless people have started submitting MRs against the GitLab instance and you are more than welcome to do so.
As far as the official upstream repository, indeed gitlab.haskell.org/ghc/ghc is still mirroring git.haskell.org/ghc. This will change when I formally announce the switchover.
Cheers,
- Ben

Gabor Greif
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.htm...

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
Gabor Greif
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.htm...

(following-up own mail)
This seems resolved too. I have submitted my branch into the main
repo, and now the pipeline is executing :-)
Still, do we want running pipelines for external contributors too?
Gabor
On 12/22/18, Gabor Greif
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
wrote: Gabor Greif
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.htm...

Gabor Greif
(following-up own mail)
This seems resolved too. I have submitted my branch into the main repo, and now the pipeline is executing :-)
Still, do we want running pipelines for external contributors too?
Indeed we do. Small oversight on my part; now fixed. Thanks! Cheers, - Ben

Yeah, it starts now, thanks!
However it won't terminate due to a restrictive time limit of 60 mins.
Can we have 120?
Gabor
On 12/22/18, Ben Gamari
Gabor Greif
writes: (following-up own mail)
This seems resolved too. I have submitted my branch into the main repo, and now the pipeline is executing :-)
Still, do we want running pipelines for external contributors too?
Indeed we do. Small oversight on my part; now fixed.
Thanks!
Cheers,
- Ben

Gabor, you can configure this yourself.
1. Go to https://gitlab.haskell.org/ggreif/ghc/settings/ci_cd
2. Expand the top drop-down "General pipelines"
3. Set the timeout to 6h
On Sun, Dec 23, 2018 at 2:30 PM Gabor Greif
Yeah, it starts now, thanks!
However it won't terminate due to a restrictive time limit of 60 mins. Can we have 120?
Gabor
On 12/22/18, Ben Gamari
wrote: Gabor Greif
writes: (following-up own mail)
This seems resolved too. I have submitted my branch into the main repo, and now the pipeline is executing :-)
Still, do we want running pipelines for external contributors too?
Indeed we do. Small oversight on my part; now fixed.
Thanks!
Cheers,
- Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Gabor Greif
Yeah, it starts now, thanks!
However it won't terminate due to a restrictive time limit of 60 mins. Can we have 120?
I have actually changed the default to six hours since Windows builds tend to easily eat through three hours at least. I've made this change on your fork. Cheers, - Ben
participants (3)
-
Ben Gamari
-
Gabor Greif
-
Matthew Pickering