You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It does but requires some jiggerypockery. That's the simplest bit of nonsense to get a 3.5 interpreter. We're doing that on python-docs-samples. (oauth2client is going the other route with a build matrix).
I'd prefer the matrix build setup, myself: having the individual language version builds parallelize would be a Good Thing(TM). I think we might even get a karma bump on the Travis side, because the individual builds wouldn't run 10+ minutes. Here is the Pyramid setup:
@jonparrott Our current PR builds on Travis take between 3.5 - 5 minutes to run. With parallelization, each environment's build would run in ~ 20 seconds (for the stock python environments) to 30 seconds (lint, cover). Those builds ought to be easier to schedule across Travis' infrastructure, and shouldn't be penalized if things are rational. We could of course get a "touchtone" effect, where we get charged / penalized for doing something which actually saves the company resources.
@jonparrott You are arguing that we get throttled based only on the number of our builds, and not on how long they take to run? Is there evidence for that?
@tseaver it's both. The problem is that travis only allows n concurrent builds and there is scheduling overhead with each build. With a matrix, this project can consume all of our concurrent builds simultaneously and not necessarily finish any faster than without the matrix.
Please take into account that Travis CI is an open source service and we rely on worker boxes provided by the community. So please only specify as big a matrix as you actually need.
Activity
dhermes commentedon Sep 19, 2016
FWIW we could remove 2.7 since all those are included in
tox -e covertseaver commentedon Sep 19, 2016
Maybe in conjunction with #2070?
theacodes commentedon Sep 19, 2016
We should do this. The Python runtime for GAE flex is about to update to 3.5
I'd recommend just adding this to
travis.yaml, as it's simpler than trying to coax the current setup into a matrix:dhermes commentedon Sep 19, 2016
Oh. You're saying Travis doesn't support 3.5 yet?
theacodes commentedon Sep 19, 2016
It does but requires some jiggerypockery. That's the simplest bit of nonsense to get a 3.5 interpreter. We're doing that on python-docs-samples. (oauth2client is going the other route with a build matrix).
dhermes commentedon Sep 19, 2016
Does it have to be
sudoto use those addons?tseaver commentedon Sep 19, 2016
I'd prefer the matrix build setup, myself: having the individual language version builds parallelize would be a Good Thing(TM). I think we might even get a karma bump on the Travis side, because the individual builds wouldn't run 10+ minutes. Here is the Pyramid setup:
.travis.ymldhermes commentedon Sep 19, 2016
@tseaver My fear is that doing a matrix build counts each build as 8 (or 9 or 10) builds, which would add even more throttling.
theacodes commentedon Sep 19, 2016
Nope.
This is correct, the bigger the matrix the more you'll get throttled, and the more you'll end up throttling the rest of us.
tseaver commentedon Sep 20, 2016
@jonparrott Our current PR builds on Travis take between 3.5 - 5 minutes to run. With parallelization, each environment's build would run in ~ 20 seconds (for the stock python environments) to 30 seconds (lint, cover). Those builds ought to be easier to schedule across Travis' infrastructure, and shouldn't be penalized if things are rational. We could of course get a "touchtone" effect, where we get charged / penalized for doing something which actually saves the company resources.
theacodes commentedon Sep 20, 2016
@tseaver I agree in principle but not in practice. Every entry in your build matrix is going to be treated as a separate build to travis.
dhermes commentedon Sep 20, 2016
@tseaver Empirically, it seems that the cost of scheduling overwhelms the run time of the scheduled tasks.
tseaver commentedon Sep 20, 2016
@jonparrott You are arguing that we get throttled based only on the number of our builds, and not on how long they take to run? Is there evidence for that?
theacodes commentedon Sep 20, 2016
@tseaver it's both. The problem is that travis only allows n concurrent builds and there is scheduling overhead with each build. With a matrix, this project can consume all of our concurrent builds simultaneously and not necessarily finish any faster than without the matrix.
daspecster commentedon Sep 21, 2016
FWIW
https://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix
theacodes commentedon Dec 2, 2016
Just an update: The Python 3 runtime for GAE flex now defaults to 3.5.2.
dhermes commentedon Dec 2, 2016
We run 3.5 on Travis / CircleCI
chore(main): release 1.23.4 (#2350)
refactor: fix group_by compiler with dtype convertions (#2350)