alain.odea at gmail.com
Tue Apr 1 11:08:13 UTC 2014
From what I understand Travis CI limits running time for each build. We may be able to create binaries of stage1 and/or stage2 in one build and test them in another. We could also fan out the test process using a Build Matrix to let GHC's full suite fit into the time limit as fragments. That would require some changes to the testsuite or some lengthy build scripts for each segment that explicitly run many "make TEST=sometest" commands.
I had to do something similar at Verafin because the whole test suite was taking too long as a whole unit. I split it into builds for each separate module and used more build agents so they could run in parallel. Verafin is using TeamCity, but I think the concepts are achievable in Buildbot or Travis CI.
In my opinion, the best build and CI system is the one you can get working.
> On Apr 1, 2014, at 10:46, Joachim Breitner <mail at joachim-breitner.de> wrote:
> Am Dienstag, den 01.04.2014, 10:25 +0000 schrieb Simon Peyton Jones:
>> Joachim Breitner has set up Travis-CI. (I don't know exactly what
>> that is, but it sounds useful.)
> Travis is a free cloud service that runs arbitrary tests (in our case, a
> stripped version of validate) upon pushes to git repositories on github.
> I set it up to validate our master, so we get a nice history of
> successes and failures on
> and I get mails when things fail; that is when I send hopefully polite
> enough mails to ghc-dev, asking people to fix their commits.
> (Unless I broke it myself; then I silently fix it and hide.)
> It is a makeshift solution until we get our own infrastructure working.
>> An early question would be: to continue to use a DIY system (Builder),
>> or to move to some other better-supported (but perhaps less malleable)
>> system. I don't even know what the options are.
> Sigh, test infrastructure are like content management systems: There are
> plenty out there to choose from, all can do lots of things one does not
> need, but none can do all, so one starts writing something selfmade,
> which eventually evolves in yet another of these beasts, just with fewer
> I’d recommend a move to existing, proven tools. Unfortunately, I cannot
> give advice as to what tool to move to. But if all these¹ projects are
> happy with buildbot, it might not be the worst choice.
> ¹ http://trac.buildbot.net/wiki/SuccessStories
> Joachim “nomeata” Breitner
> mail at joachim-breitner.de • http://www.joachim-breitner.de/
> Jabber: nomeata at joachim-breitner.de • GPG-Key: 0x4743206C
> Debian Developer: nomeata at debian.org
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs