[Cython] Jenkins jobs refactored

[Robert Bradshaw]

On Tue, Sep 6, 2011 at 1:58 PM, Stefan Behnel <stefan_ml at 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