Personally, I would prefer not to increase the test run time by that much. I think once we change this setting it will be hard to change it back, because people will introduce tests that don't clean up after themselves. For example, the integration tests are currently set to fork every 1 test, and that can't be undone without a bunch of clean up work.
I'd rather work gathering/cleaning up static fields that might cause problems, and adding assertions they haven't changed or clearing them after every test. -Dan On Fri, Sep 4, 2015 at 12:43 PM, Jacob Barrett <[email protected]> wrote: > Can any of them be launched in parallel? This could cut down time > significantly. > > > > > Jacob Barrett > Manager > GemFire Advanced Customer Engineering (ACE) > Pivotal > > [email protected] > 503-533-3763 > > For immediate support please contact Pivotal Support at > http://support.pivotal.io/ > > On Fri, Sep 4, 2015 at 11:17 AM, Mark Bretl <[email protected]> wrote: > > > I see that Kirk made an update to the issue and wanted to follow up on > the > > Dev list for discussion. > > I also ran a build on the open side with the dunit fork = 1. The total > time > > of the build was: 9 hrs 58 mins 33.662 secs. The last Geode build took: 6 > > hr 21 min <https://builds.apache.org/job/Geode-nightly/buildTimeTrend>. > > It is an increase of about 3.5 hours, which matches the increase in time > > that Kirk had. > > The question becomes: Do we want to make the change so we can increase > the > > quality of tests by isolating each one at the cost of increasing the > total > > build time? > > My thoughts would be to make the change to weed out the 'bad' tests and > > increase the overall quality of the tests, so when a test fails there is > no > > questioning the result. Once we have them passing more consistently, then > > we can increase the fork count again. > > Thoughts? > > -- > > Mark Bretl > > Software Build Engineer > > Pivotal > > 503-533-3869 > > www.pivotal.io >
