Re: [core-workflow] travis bottleneck at sprints

On May 25, 2017, at 4:49 PM, Brett Cannon wrote:

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

Just to be completely accurate, PyPA and PyCA had independent quotas for a long time (The default is uh, 5 I think, and both PyPA and PyCA had 10). When I reached out to Travis about getting the same for CPython, they came up with the idea of sharing a quota to allow CPython a chance to burst higher without having to add yet another dedicated queue for CPython. This generally ends up being a net positive for everyone since everyone gets a chance at a much larger burst capacity and between the three orgs we don’t generally have *too* much contention. I can reach out to Travis though about the possibility of a temporary bump during large sprints. Another option might be to reduce the human bottleneck by allowing a bot to auto merge once tests pass (although that adds more dev work of course). That way people can review and mark as approved (or even explicit to auto merge) and once tests catch up the bot handles merging it. That would allow people to generally move on once everything but waiting on tests + pressing merge button is done. — Donald Stufft