FWIW Beam has "pre-commit" and "post-commit" suites [1], with the latter being quite a lot longer and including lots of integration tests with e.g. cloud data processing engines and storage systems, so at least the tests have a home. You get "quick" feedback on pull requests (let's ignore how slow our pre-commit is...) and for things that take hours and you find out in post-commit you can always roll back [2]. You can do a bit of engineering with the Jenkins groovy DSL to make this not so painful to administer [3].
Kenn [1] https://builds.apache.org/view/A-D/view/Beam/ [2] https://beam.apache.org/contribute/postcommits-policies/ [3] https://github.com/apache/beam/tree/master/.test-infra/jenkins On Wed, Oct 24, 2018 at 8:02 PM Julian Hyde <[email protected]> wrote: > You exaggerate a little. It does test Calcite code, not just hsqldb. > > We should add a “slow regression test”, and add some of the tests in > LatticeTest to it. We can disable it in the regular suite once that > regression test is up and running regularly. > > Julian > > > > On Oct 24, 2018, at 12:29 PM, Vladimir Sitnikov < > [email protected]> wrote: > > > > I'm inclined to do something with LatticeTest (== mark it as disabled or > > something like that) > > It fails too often, and the only thing it does it tests HSQL (or H2?) > > ability to perform join queries. It has nothing to do with Calcite. > > > > Current LatticeTests definitely harms Calcite development and it makes > > "Calcite-Master - Build # 944 - Still Failing" messages virtually > useless. > > > > Vladimir > >
