[core-workflow] travis bottleneck at sprints

[Brett Cannon]

Donald is our contact with Travis, so I've explicitly added him to this
email.

To give some details: we get 25 concurrent jobs across all the various
"official" Python projects on GitHub hosted under the Python, PyPA, and
PyCA organizations (which is a substantial bump from what most projects
get; see https://travis-ci.com/plans to get an idea of what we're getting
for free). CPython itself uses 3 of those with any single PR or merge into
a branch (docs, Py_DEBUG, coverage).

Now normally this works out great for us since CPython is probably one of
the more active projects that gets to use this increased budget, and so we
typically take a chunk of the 25 concurrent builds happily and get our
builds started very promptly. But at the sprints we ran up against
cryptography and their crazy build needs:
https://travis-ci.org/pyca/cryptography . IOW having every major Python
project using Travis' free service at once hit us hard.

As to whether we can get more of a budget for the sprints at PyCon US (or
any other conference), I don't know. Maybe Donald could tell us more detail
and/or find out if next year we can plan ahead to get a temp boost for the
four days. Otherwise we're talking about making PyCA suffer year-round by
having them have to get their own quota or something.


On Wed, 24 May 2017 at 14:46 Guido van Rossum <guido at python.org> wrote:

> I've noticed that too; the python/mypy project is also experiencing slow
> builds (as is mypy/typeshed). I don't know how to contact Travis for this
> though.
>
> On Wed, May 24, 2017 at 2:38 PM, Eric Snow <ericsnowcurrently at gmail.com>
> wrote:
>
>> tl;dr  Could we temporarily bump our cap on concurrent travis builds
>> during sprints?
>>
>> During the sprints at PyCon we've been running into a serious
>> bottleneck with travis.  Having an extra allowance for builds already
>> is great, but during sprints even that gets swamped.  I am not sure
>> what projects contribute most to the problem, but I'm pretty sure it
>> isn't CPython (essentially 2 builds per PR).  Regardless, with the new
>> workflow this bottleneck significantly impacts the higher pace that
>> usually takes place at sprints.  Would it make sense to see if the
>> Travis folks would be willing to bump our limit temporarily during
>> each sprint?
>>
>> -eric
>> _______________________________________________
>> core-workflow mailing list
>> core-workflow at python.org
>> https://mail.python.org/mailman/listinfo/core-workflow
>> This list is governed by the PSF Code of Conduct:
>> https://www.python.org/psf/codeofconduct
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170525/52c34730/attachment.html>