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/ > 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. Stefan _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
