[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