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@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@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@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@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