BTW, I modified the “Geode in 5 min” wiki page to include build instructions for skipping tests. I’ll do the same for README.md unless I hear any objections.
Anthony > On Sep 4, 2015, at 12:33 PM, Anthony Baker <[email protected]> wrote: > > Another note: these timings are from server-class workstations. On a laptop > the overall test length (without the change) can run 18+ hours. > > Anthony > > > >> On Sep 4, 2015, at 12:21 PM, Kirk Lund <[email protected]> wrote: >> >> +1 >> >> I like the idea of switching to fork=1 for a few months to focus on >> stabilizing any dunit tests that fail without potential test pollution >> causes. These failures are mostly like ones that involve race conditions. >> Once we fix these, then we could change back to fork=30. >> >> >> On Fri, Sep 4, 2015 at 11:16 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 >>> >
