> On 06 Nov 2015, at 14:36, Sebastian Schuberth <sschube...@gmail.com> wrote: > > On Fri, Nov 6, 2015 at 2:28 PM, Lars Schneider <larsxschnei...@gmail.com> > wrote: > >> Well, I partly agree. Right now the running time is ~20 min (that means less >> than your 30min target!). After ~10min you even have all Linux results, Mac >> takes a bit longer. Travis shows you 2h because that is the time that would >> be required if all builds where run one after another (we run builds in >> parallel). > > Are you sure about than? I mean, what sense does it make to show how > long it *would* have taken *if* the builds were running serially? I > can see that the longest of the jobs took 21 minutes, which is ok. But > that does not mean that all jobs completed in within 21 minutes. It > could be that not all jobs started at (about) the same time due to a > lack of resources, and that the last job did not compete before the 2 > hours were over because it only started to run 1 hours and 40 minutes > befor ethe first job was started. I am fairly certain about this.
See, here is the first configuration and the first test case of a job: https://travis-ci.org/larsxschneider/git/jobs/89598195 [08:21:06] t0002-gitfile.sh Here is the last configuration and the last test case of the same job: [08:51:22] t9903-bash-prompt.sh ~30 min for all 8 configurations. You can enable Travis CI for you GitHub account and try it easily yourself :-) > >> That being said, I see your point of to avoiding to burn Travis CI resources >> meaningless. If I am not mistaken then you can configure Travis in a way >> that it runs different configurations for different branches. E.g. I would >> like to run all 8 configurations on maint, master, next and maybe pu. All >> other branches on peoples own forks should be fine with the default Linux >> build (~10min). >> >> What do you think? > > I think running different configuration per branch makes sense, yes. If the list decides to accept this patch. Do you think that would be a necessary requirement for the first iteration? Thanks, Lars-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
