On Tue, Sep 6, 2011 at 1:58 PM, Stefan Behnel <stefan...@behnel.de> wrote: > Robert Bradshaw, 06.09.2011 22:21: >> >> On Tue, Sep 6, 2011 at 1:12 PM, Stefan Behnel wrote: >>> >>> I replaced the half-a-ton of cython-devel jobs in Jenkins by three >>> multi-configuration matrix jobs: >>> >>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-build/ >>> >>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/ >>> >>> >>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/ >>> >>> The sdist job that does the git checkouts is unchanged: >>> >>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-sdist/ >>> >>> This setup only slightly reduces the flexibility of the overall >>> configuration, but it greatly reduces the maintenance overhead for the >>> jobs >>> and makes it much easier to keep their configuration aligned. >> >> Nice. >> >>> The only downside is that it that all build jobs must terminate before >>> the >>> tests are triggered. Given that the turn-over times are quite low, I >>> don't >>> think that's a problem. Quite the contrary, if one of the PyX.Y builds >>> fails, none of the test jobs will run, which I think is a good thing. >> >> The one drawback is this seems to make it hard to implement the idea >> of testing 2.4, 2.7, and 3.2 before building and testing all the rest >> for quicker feedback? > > Partly. All build jobs will have to terminate first, yes, but Jenkins has a > notion of a "touchstone build", which allows to configure certain builds in > the matrix that should run first. So, after all PyX.Y builds are ready, > Py2.4/7 and Py3k will be tested first. That way, the feedback is a little > slower than today, but it still prefers the important platforms.
That sounds find. If the build breaks, I'm fine with forcing that to be fixed before going on to testing. - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
