[Testing] Using Travis CI (or better alternative) for master/branch/PR testing

[Iain Buclaw via D.gnu]

On 22 June 2015 at 19:58, Johannes Pfau via D.gnu <d.gnu at puremagic.com> wrote:
> Am Mon, 22 Jun 2015 08:56:53 +0000
> schrieb "Iain Buclaw" <ibuclaw at gdcproject.org>:
>
>> As the autotester seems to be broken indefinitely for the time
>> being, I've been playing around with Travis for builds.
>>
>> https://travis-ci.org/ibuclaw/GDC/branches
>>
>> A couple of show stoppers I've been running into:
>> - Time to build, run testsuite, run unittests exceeds quota (50
>> minutes)
>> - Memory consumption exceeds quota (claims to be a hard 3GB)
>>
>> This is interesting, to speed up builds it might be considered
>> logical to increase the number of parallel jobs, infact this
>> conflicts directly with the memory consumption quota, meaning
>> that the build needs to be carefully split up to run at different
>> parallel levels depending on the memory used.
>>
>> What seems to be a total blocker is that I seem to be getting
>> inconsistent results (in relation to out-of-memory errors)
>> depending on which host the build is running on.
>
> Maybe drop them a mail if they would consider upgrading the quotas
> for GDC. Regarding inconsistent results: If it's related to the build
> environment using docker might help?
>

I suspect that would require money. https://travis-ci.com/plans

(Their production build servers allow up to 2 hours)

The environment should be clean upon each new build.  The problem I
suspect is dependent on the current load of the host server where the
VM / Sandbox is running.  If it is already under high load (or not),
this may drastically change the order of which sources are compiled in
parallel.

What I should do is split up the testsuite and unittests into two
different environments, this will give us a better chance to complete
in the short timeframe.

On the topic of keeping memory down.  What I'd like to do eventually
is to integrate at least all glue structures into the GCC GC.  It
might also be possible to free up all front-end allocated memory too
once we've finished generating all codegen.  This is something that
will need to be investigated (add it to our todo list?)

>
> BTW: I'd also like to run build-tests for arm and mingw in the future.
> We could simply test if we can build the x86_64=>mingw/arm
> cross-compilers.
>
> I'm currently preparing the last changes for crosstool-ng and once
> that's done I'll publish the docker container to build the
> gdcproject.org downloads. Then building the cross compilers will be as
> simple as:
>
> docker run -v docker-shared:/home/build/shared -t
> gdc/build-gdc /usr/bin/build-gdc build
> --toolchain=x86_64-linux-gnu/gcc-snapshot/x86_64-w64-mingw32

Cool, I suspect you will still need to apply the memory hack for ld
though as I have done.

Iain.