Re: [DISCUSS] reasonable duration for tests in the Calcite codebase
FWIW Beam has "pre-commit" and "post-commit" suites , 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 . You can do a bit of
engineering with the Jenkins groovy DSL to make this not so painful to
On Wed, Oct 24, 2018 at 8:02 PM Julian Hyde <jhyde@xxxxxxxxxx> 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.
> > On Oct 24, 2018, at 12:29 PM, Vladimir Sitnikov <
> sitnikov.vladimir@xxxxxxxxx> 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
> > Vladimir