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
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
> p
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
would like to check that I don't break something on
platforms I don't have access to and check for performance regressions.
I'm not sure there is a way to manually trigger the CI pipeline. If
you really want to you could modify the .gitlab-ci.yml file on your
branch.
I've just read on [1] that we
Yes, this is an consequence of a bug in gitlab which meant that pushes
to branches which were also MRs were built twice.
I'm not sure there is a way to manually trigger the CI pipeline. If
you really want to you could modify the .gitlab-ci.yml file on your
branch.
If you want your commit
Hi devs,
It seems that the CI doesn't check branches in GHC forks on Gitlab
anymore. Is is intentional? Is there a way to trigger a CI execution
manually on a specific branch?
Thanks,
Sylvain
___
ghc-devs mailing list
ghc-devs@haskell.org
http
Hello everyone,
Note that yesterday I moved CI artifact storage from AWS to
Dreamobjects. However, I was not able to move the old artifacts
themselves (transferring >500 GB of data that will largely be expired in
two weeks between cloud providers is simply not economically feasible).
Consequen
Richard Eisenberg writes:
> How will this affect workflow of developers submitting patches? For
> example, suppose I write a user-facing change that breaks some of
> these packages. Am I expected to patch up the breakage? How? Will the
> CI infrastructure detect this before merg
How will this affect workflow of developers submitting patches? For example,
suppose I write a user-facing change that breaks some of these packages. Am I
expected to patch up the breakage? How? Will the CI infrastructure detect this
before merging or after?
To be clear, I don't have specific
Ryan Scott writes:
> This is fantastic work! I'm looking forward to using this.
>
> Are there plans to merge GitLab's fork of head.hackage back into the
> upstream repo [1]? I ask since I regularly submit patches to upstream, but
> if the GitLab CI is using the fork, then it may
This is fantastic work! I'm looking forward to using this.
Are there plans to merge GitLab's fork of head.hackage back into the
upstream repo [1]? I ask since I regularly submit patches to upstream, but
if the GitLab CI is using the fork, then it may take some time for upstream
changes to make
Hello everyone,
As many of you know, recently I have been working on bringing up
infrastructure for using CI-produced binary distributions to build a
subset of Hackage using the head.hackage patchset.
Happily, this effort has now converged on a usable result, embodied in
two merge requests
ac #16346.
>
> The question is: how did it get past CI?
>
> The bug would only show up if -dcore-lint was on for libraries.
>
> Simon
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Ben, Matthew
I believe that 'master' fails validate. See Trac #16346.
The question is: how did it get past CI?
The bug would only show up if -dcore-lint was on for libraries.
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org
Alp has pointed me to the right place.
https://gitlab.haskell.org/ghc/ghc/tree/master/.circleci/images
Can someone give me access to push to the ghcci docker hub please so I
can update them?
Matt
On Mon, Feb 18, 2019 at 4:35 PM Matthew Pickering
wrote:
>
> Hi Mark, Ben
>
> Where are the
Hi Mark, Ben
Where are the dockerfiles (or nix expressions) which are used to build
the docker images? I want to update them and push some new images to
ghcci but I can't find any trace about how the images have been made.
Cheers,
Matt
___
ghc-devs
Richard Eisenberg writes:
> So, just checking: is the recommended route to merging now to use the
> Marge Bot instructions posted previously? (That is, get 1+ approvals
> and then assign to Marge.)
>
Indeed. I was just sent an email reiterating the previous guidance to
the list.
Cheers,
- Ben
Indeed Marge was causing a remarkable amount of CI traffic, leading to
> long queues, and eventually build timeouts. Thankfully Matthew
> investigated why Marge's batch mode wasn't batching and consequently
> things should now be much better.
>
> S
o start over.
>
Indeed Marge was causing a remarkable amount of CI traffic, leading to
long queues, and eventually build timeouts. Thankfully Matthew
investigated why Marge's batch mode wasn't batching and consequently
things should now be much better.
Sorry for the previous inconvenience!
19, 13:56 Matthew Pickering
> wrote:
>>
>> It has been established today that Marge is failing to run in batch
>> mode for some reason which means it takes at least as long as CI takes
>> to complete for each commit to be merged. The rate is about 4
>> commits/day with the
t;bot wackamole" :)
On Sun, Feb 3, 2019, 13:56 Matthew Pickering
wrote:
> It has been established today that Marge is failing to run in batch
> mode for some reason which means it takes at least as long as CI takes
> to complete for each commit to be merged. The rate is about 4
> commit
Hi,
Am Sa., 2. Feb. 2019 um 16:09 Uhr schrieb Matthew Pickering <
matthewtpicker...@gmail.com>:
>
> All the other flavours should be run once the commit reaches master.
>
> Thoughts?
>
That's even better than my idea of only running them as nightlies. In favor!
> Cheers,
>
> Matt
>
Hi all,
Everyone has probably noticed that getting anything merged is a real
effort at the moment. The main problem is that CI takes in the region
of 5-7 hours and then spuriously fails at the end. After 5-7 hours you
have to rebase and run CI again and so on. Therefore I propose to run
just
Hi,
Am Sonntag, den 27.01.2019, 09:56 -0500 schrieb Richard Eisenberg:
> Clearly, having a CI trace of this would simplify things -- not to
> mention catch bugs earlier.
absolutely agree, and I can’t help but notice that our first CI setup
on travis that I created four years ago had a
e would do. In any case, my goal in this email
> is not to convince you to follow suit. My goal is to request that our
> CI infrastructure include at least one testsuite run in a DEBUG
> compiler. A patch I'm working on is failing a test because of an
> assertion failure. I doubt my pa
is not to convince you to follow
suit. My goal is to request that our CI infrastructure include at least one
testsuite run in a DEBUG compiler. A patch I'm working on is failing a test
because of an assertion failure. I doubt my patch is the culprit, but I also
can't categorically rule it out. So, I'm
Richard Eisenberg writes:
> Marge has complained that
> https://gitlab.haskell.org/rae/ghc/-/jobs/17206 is taking too long.
> And indeed it seems stuck.
>
Indeed currently CI is a bit backed up. There are a few reasons for
this:
* I am currently in the middle of a (now two-day-lo
Marge has complained that https://gitlab.haskell.org/rae/ghc/-/jobs/17206 is
taking too long. And indeed it seems stuck.
Help?
Thanks,
Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
s upstream as a group and becomes
> a permanent part of the branch's history. Unless someone force-pushes the
> branch afterward, forcibly overwriting that history with a different one
> and leaving anyoneelse who'd checked out the branch with dangling commits
> that no longer exist.)
>
that no longer exist.)
Here, CI is making a copy of someone's branch and testing each commit in
turn to ensure consistency between multiple branches that touch the same
code, whose commits may end up interleaved. If the branch is rebased or
force-pushed during that testing, intermediate commits may become
| Sent: 24 January 2019 19:22
| To: Ben Gamari
| Cc: GHC developers
| Subject: Re: "resource exhausted" in CI
|
| Ah, yes -- I did push a rebase. OK: good to know that this is expected
| behavior after rebasing (makes sense).
|
| Thanks,
| Richard
|
| > On Jan 24, 2019, at 2:01 P
Ah, yes -- I did push a rebase. OK: good to know that this is expected behavior
after rebasing (makes sense).
Thanks,
Richard
> On Jan 24, 2019, at 2:01 PM, Ben Gamari wrote:
>
> Richard Eisenberg writes:
>
>> Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got
>>
Richard Eisenberg writes:
> A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807
>
> The failures are just some output changes. I could delicately use the
> log to extract the changes and commit them, but it would be better to
> have direct access to, say, the *.run.stderr
Richard Eisenberg writes:
> Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got
> off the ground.
>
It is possible that you pushed a rebase? This error generally means that
the commit is no longer accessible which may happen when you push a
rebase.
I believe I cited
A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807
The failures are just some output changes. I could delicately use the log to
extract the changes and commit them, but it would be better to have direct
access to, say, the *.run.stderr files and then commit those. Is
: recipe for target 'compiler/stage2/build/TcTyClsDecls.o'
failed
make[1]: *** [compiler/stage2/build/TcTyClsDecls.o] Error 1
make[1]: *** Waiting for unfinished jobs
Is there a way to avoid this? Or should I just restart the CI? And what does
Marge think of it all? (As in, if I ask her to take
Am Sa., 5. Jan. 2019 um 22:18 Uhr schrieb Ben Gamari :
However, we can certainly use the upstream repo during CI builds.
I have opened !78 which should hopefully fix this. Perhaps you could
rebase on topp of this and check?
>
Thanks, Ben, that works for me.
What I hadn't realized bef
Simon Jakobi via ghc-devs writes:
> Hi,
>
> I just tried to use GitLab CI to validate a GHC patch including changes to
> Haddock: https://gitlab.haskell.org/sjakobi/ghc/pipelines/842
>
> The problem is that the CI script tries to find my Haddock commit at
> https://gitlab.ha
Gabor Greif writes:
> 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
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 wrote:
>
> Yeah, it starts now, thanks!
>
> However it won't terminate due
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
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!
e
> 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,
>>>
>
g 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 s
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
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
Hi everyone,
As you likely have noticed, GHC's CI is a bit of a mess since the
Hadrian merge, especially for differentials based on commits prior to
the merge. The problem is a tiresome limitation of Harbormaster's CI
strategy [1].
I have taken this opportunity to finally move testing
Hello devs,
OSX CI seems to have testsuite failures since at least 44ba66527ae2
<https://phabricator.haskell.org/rGHC44ba66527ae207ce2dd64eb2bce14656d474f6d1>
(but likely caused by something else) and started sometime after
966aa7818222
<https://phabricator.ha
, Artem Pelenitsyn
> wrote:
> > Hello, devs,
> >
> > Could someone point me where I go wrong in the following? My
> Differentials
> > constantly fail to CI with the messages like this one:
> >
> > exception 'PhabricatorWorkerPermanentFailureException' with
erentials
> constantly fail to CI with the messages like this one:
>
> exception 'PhabricatorWorkerPermanentFailureException' with message 'Lease
> "PHID-DRYL-sydepw7hjxlnim325sdu" never activated.' in
> /opt/phabricator/src/applications/harbormaster/step/HarbormasterLeaseWorking
Hello, devs,
Could someone point me where I go wrong in the following? My Differentials
constantly fail to CI with the messages like this one:
exception 'PhabricatorWorkerPermanentFailureException' with message 'Lease
"PHID-DRYL-sydepw7hjxlnim325sdu" never activated.' in
/opt/phabr
It should be ok with the following revert:
https://git.haskell.org/ghc.git/commitdiff/0e37361392a910ccbbb2719168f4e8d8272b2ae2
On 17/04/2018 02:54, David Feuer wrote:
On Monday, April 16, 2018 9:16:37 PM EDT Simon Peyton Jones wrote:
I wonder if you are compiling with 8.2.1? It's broken.
I wonder if you are compiling with 8.2.1? It's broken. You need 8.2.2
| -Original Message-
| From: ghc-devs <ghc-devs-boun...@haskell.org> On Behalf Of David Feuer
| Sent: 16 April 2018 18:22
| To: ghc-devs@haskell.org
| Subject: CI builds failing
|
| It looks like the
It looks like the recent differential builds are all failing like this:
compiler/main/DynamicLoading.hs:79:19: warning: [-Wunused-matches]
Defined but not used: ‘hsc_env’
|
79 | initializePlugins hsc_env df
| ^^^
ghc: panic! (the 'impossible' happened)
(GHC
Wed, Sep 6, 2017 at 7:05 PM, GHC <ghc-devs@haskell.org> wrote:
>
>> #13716: Move CI to Jenkins
>> -+--
>> ---
>> Reporter: bgamari |Owner: (none)
>>
Thats actually how this project started.
On Wed, Sep 6, 2017 at 7:05 PM, GHC <ghc-devs@haskell.org> wrote:
> #13716: Move CI to Jenkins
> -+--
> ---
> Reporter: bgamari |
Hi *,
TL;DR Phabricator will go down for about 5 minutes later today, but
the CI will be off for a while longer.
I wanted to alert everyone: I'll be upgrading Phabricator shortly this
morning, after doing a bunch of testing to make sure our upgrade will
go smoothly.
Luckily, it will go quite
er this morning so the build queue is now empty.
> Hold tight.
>
> On Thu, Jan 21, 2016 at 7:07 AM, Austin Seipp <aus...@well-typed.com> wrote:
>> Hi *,
>>
>> TL;DR Phabricator will go down for about 5 minutes later today, but
>> the CI will be off for a while lo
te:
>>> Hi *,
>>>
>>> TL;DR Phabricator will go down for about 5 minutes later today, but
>>> the CI will be off for a while longer.
>>>
>>> I wanted to alert everyone: I'll be upgrading Phabricator shortly this
>>> morning, after doing a
about 5 minutes later today, but
> the CI will be off for a while longer.
>
> I wanted to alert everyone: I'll be upgrading Phabricator shortly this
> morning, after doing a bunch of testing to make sure our upgrade will
> go smoothly.
>
> Luckily, it will go quite smoothly. Th
gured out what was wrong with the Travis CI build for Haskell
> Platform, and got it all working w/hvr's .debs of GHC (for the boot
> compiler)... and ran smack into this:
>
> Your test run exceeded 50 minutes.
>
>
> SO... I'd like to find another CI solution. Is phabricator.h
: Sun, Jun 7, 2015 at 11:33 AM
Subject: the platform has outgrown Travis-CI
To: haskell-platf...@projects.haskell.org
haskell-platf...@projects.haskell.org, ghc-devs@haskell.org
ghc-devs@haskell.org, haskell-infrastruct...@community.galois.com
haskell-infrastruct...@community.galois.com
I
might've changed.
On Sun, Jun 7, 2015 at 11:33 AM, Mark Lentczner mark.lentcz...@gmail.com
wrote:
I finally figured out what was wrong with the Travis CI build for Haskell
Platform, and got it all working w/hvr's .debs of GHC (for the boot
compiler)... and ran smack into this:
Your test run
.
-- Dan
On Sun, Jun 7, 2015 at 12:33 PM, Mark Lentczner mark.lentcz...@gmail.com
wrote:
I finally figured out what was wrong with the Travis CI build for Haskell
Platform, and got it all working w/hvr's .debs of GHC (for the boot
compiler)... and ran smack into this:
Your test run exceeded 50
Mark Lentczner wrote:
I finally figured out what was wrong with the Travis CI build for Haskell
Platform, and got it all working w/hvr's .debs of GHC (for the boot
compiler)... and ran smack into this:
Another option you or others may want to pursue is setting up a self
manager Jenkins
I finally figured out what was wrong with the Travis CI build for Haskell
Platform, and got it all working w/hvr's .debs of GHC (for the boot
compiler)... and ran smack into this:
Your test run exceeded 50 minutes.
SO... I'd like to find another CI solution. Is phabricator.haskell.org an
option
Hi,
Am Freitag, den 22.11.2013, 23:23 + schrieb Joachim Breitner:
It is updated regularly (currently a cronjob every 15 minutes, ideally
by push hooks), and each push triggers a build of exactly these recorded
versions of all components via travis:
.
So it is a useful tool, and I would like to see it at
https://travis-ci.org/ghc/ghc-complete/ghc instead, i.e. not tied to my
name. Unfortunately, I cannot do that myself. Therefore, if you agree
that this is a good thing (until we have a CI of our own), would someone
with appropriate permissions
. Unfortunately, I cannot do that myself. Therefore, if you agree
that this is a good thing (until we have a CI of our own), would someone
with appropriate permissions please
* Pull the repo from https://github.com/nomeata/ghc-complete to
git.haskell.org.
* Set up the mirror on github.com/ghc for ghc
101 - 169 of 169 matches
Mail list logo
