In the case of failed builds because of exceeding runtime, it means there are still tests left not run. Do we still merge the PR? What if one of the leftover tests is the one related to the proposed code change?
On Thursday, October 23, 2014 1:18:51 AM UTC+7, Rafael Mendonça França wrote: > > In fact we already have parallelization, but it doesn’t work on Travis > because we only have one core in our machines. > > To run railties tests in parallel you only need to specify the CORES > environment variable. > > CORES=4 rake test > > I don’t think it is worth to split this build, it doesn’t fail often, and > even if it does we don’t take in consideration before merging. We prefer to > fix the build after merging than wait the build to run and ask contributors > to fix the build. > > > Rafael Mendonça França > http://twitter.com/rafaelfranca > https://github.com/rafaelfranca > > On Wed, Oct 22, 2014 at 4:05 PM, Chad Woolley <thewoo...@gmail.com > <javascript:>> wrote: > >> Sounds like a great idea, just make sure it doesn't break the build >> locally. >> >> For bonus points make the number of parallel builds configurable. >> For extra bonus points, make the parallelization work locally as well as >> Travis. >> >> -- Chad >> >> On Wed, Oct 22, 2014 at 9:22 AM, Tu Hoang <said...@gmail.com >> <javascript:>> wrote: >> >>> I raised this issue via Github (here >>> <https://github.com/rails/rails/issues/17358>) and got informed by >>> rafaelfranca that it's better to do this via the mailing list. Sorry, >>> Rafael; and thank you as well :-). >>> >>> A few <https://travis-ci.org/rails/rails/builds/38633209> builds >>> <https://travis-ci.org/rails/rails/builds/38715540> have been marked as >>> "Error" because (most of the time) their `GEM=railties, ruby=1.9.3` test >>> suites exceed 50 minutes. >>> >>> My suggestion is we split this particular test suite into two parallel >>> builds (by giving each build a number of test folders >>> <http://docs.travis-ci.com/user/speeding-up-the-build/>) so that >>> hopefully each build runs for about 25 minutes, which goes along with its >>> `ruby=2.0.0`, `ruby=2.1`, `ruby=ruby-head` counterparts. >>> >>> I'm still keen on this suggestion though. It: >>> >>> - reduces build time >>> - prevents repetitive (and expensive) builds, caused by slow Rubygems or >>> Bundler API >>> >>> WDYT? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ruby on Rails: Core" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to rubyonrails-co...@googlegroups.com <javascript:>. >>> To post to this group, send email to rubyonra...@googlegroups.com >>> <javascript:>. >>> Visit this group at http://groups.google.com/group/rubyonrails-core. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rubyonrails-co...@googlegroups.com <javascript:>. >> To post to this group, send email to rubyonra...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.