Always running hbase-server is equivalent to always running the build at root. It takes hours. We should not do that.
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? 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 >>
