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

Johannes Pfau via D.gnu d.gnu at puremagic.com
Mon Jun 22 10:58:05 PDT 2015


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?

> 
> Iain.

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


More information about the D.gnu mailing list