On Tue, May 10, 2016 at 11:02 PM, Sean Busbey <[email protected]> wrote:
> Always running hbase-server is equivalent to always running the build > at root. It takes hours. We should not do that. > > Agree. > An opt-in mode for Yetus that runs tests in all module that depend on > a changed module would make sense for projects that have poor module > independence. > > That said, every time this comes up, I ask the same question and no > one ever seems to have an answer: > > Why does the module that changed not have sufficient tests of its > surface that the use in other modules is properly covered? > > Good question. Thats where we should be going. Thanks Sean, St.Ack > On Tue, May 10, 2016 at 8:24 PM, Ted Yu <[email protected]> wrote: > > Contributor / committer should watch out for Jenkins builds after his / > her > > patch gets integrated. > > > > TestRpcMetrics is in hbase-server module. > > I think the QA bot should always run tests in hbase-server module. This > can > > be done by adding hbase-server to CHANGED_MODULES (if it is not included) > > in dev-support/hbase-personality.sh > > > > On Tue, May 10, 2016 at 7:57 PM, Phil Yang <[email protected]> wrote: > > > >> Hi all > >> > >> Recently I did some optimization about metrics in HBASE-15742, the patch > >> only changed the hbase-hadoop2-compat module, and pre-commit builds only > >> run the tests in this module. However, some other modules import this > >> module, and some tests failed but we didn't know before committing. I > think > >> we should run all modules that import the changed modules in pre-commit > >> builds. > >> > >> Any ideas? > >> > >> > >> > >> Thanks, > >> Phil > >> >
