On Wed, Nov 17, 2010 at 3:01 PM, Stefan Behnel <stefan...@behnel.de> wrote: > Robert Bradshaw, 17.11.2010 21:20: >> On Wed, Nov 17, 2010 at 6:55 AM, Stefan Behnel wrote: >>> One way to get relief is to reduce the currently 9 jobs that all query the >>> cython-devel repo for changes. I can try to change that by adding a >>> dedicated source build job that does the polling and triggers the real >>> build jobs that just download the sdist with no hg interaction. > > Done. > > I've also disabled the hg polling in the cython-haoyu-build-* jobs. > > >> I was actually thinking the exact same thing. Sdist is actually rather >> io-intensive, but I'd imagine all jobs pulling locally (disk-to-disk) >> triggered a single job that pulls from the web interface would be a >> big improvement. > > There's one sdist job now that finishes within seconds. It triggers all > cython-devel-build-py* jobs that only copy over the sdist and build from > it. Hudson's fingerprinting will keep track of the origin of the sources. > > We also get all test results aggregated in one place that way: > > https://sage.math.washington.edu:8091/hudson/job/cython-devel-sdist/lastBuild/aggregatedTestReport/
Cool. Thanks. >> Two other things that might help out would be (1) >> doing much of the building on boxen's RAM disk and (2) having a >> cascading system where, for example, 2.3 and 2.6 were fired off, and >> only if all their tests passed would 2.4-2.6 run. (It seems like >> there's a lot of wasteful testing going on for the non-version >> specific failures.) > > Yes, I agree. (2) can be done, but let's see where the sdist change gets us > so far. Sure. - Robert _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
