I have a patch at https://issues.apache.org/jira/browse/HADOOP-8308 which takes the approach that Alejandro outlined.
Cheers, Tom On Wed, Apr 18, 2012 at 10:11 AM, Alejandro Abdelnur <t...@cloudera.com> wrote: > Giri, > > On Tue, Apr 17, 2012 at 8:36 PM, Giridharan Kesavan > <gkesa...@hortonworks.com> wrote: >> Alejandro, >> >> On Tue, Apr 17, 2012 at 4:52 PM, Alejandro Abdelnur <t...@cloudera.com> >> wrote: >>> Giri, >>> >>> I agree that running ALL tests all time takes a lot of time >>> (personally I'd prefer we do this at the penalty of longer runs). >>> >>> Still we have a problem to solve, we need to find a solution on >>> test-patch working for ALL maven modules, currently changes outside of >>> common/hdfs/mapred or cross-projects test-patch does not work. >>> >>> So, how about the following approach: >>> >>> * All patches must be at trunk/ level >>> * All patches do a full clean TARBALL creation without running testcases >>> * From the patch file we find out the maven modules and for those >>> modules we do javac-warns/javadoc-warns/findbugs/testcases >> >> I like this approach of doing a clean tarball. >> and doing the other checks ( javac warnings, javadoc warnings, findbug >> warnings and release audit.) >> for that specific module. >> > > Great, the idea of the doing a clean tarball it to ensure that nothing > in the build/assembly is broken and that no API change breaks other > modules. > >>> >>> This would speed up test-patch runs and together with a nightly >>> jenkins jobs running ALL testcases would give a complete coverage. >>> >> >> test-patch and nightly jenkins jobs running ALL testcase? >> could you pls explain this? > > you want to verify there is no regression because of functional > changes in all modules, doing this once a day seems reasonable and > will help identify the culprit early on (that is why I said in my > original email my preference would be to run everything every time) > > thxs > > --- > Alejandro
