[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] reasonable duration for tests in the Calcite codebase

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].


[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 <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.
> Julian
> > 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
> useless.
> >
> > Vladimir