[hibernate-dev] [OGM] Move container integration test to a separate default test cycle

[Gunnar Morling]

+1 for option #1. Note that you already today can skip all integration
tests by adding -DskipITs to your Maven command.

I think it'd make sense have a single module which houses all the
integration tests which can then be executed against all possible
container/datastore combinations. By default we could run just one
combination, say ISPN on WildFly, while on CI all combinations are run via
a Matrix job (with axes being container and datastore). Starting the
servers beforehand would be a very nice improvement as well.

--Gunnar



2014-03-27 13:07 GMT+01:00 Davide D'Alto <davide at hibernate.org>:

> > My vote goes to #1 as well for the short term.
>
> +1
>
> > we need to share the running containers across
> > modules, or merge the integration tests in a single module per
> > container.
> > Not sure how far Maven will be a problem for this
>
> I think it would be easier to start and download the containers without
> using maven
> and then run the maven build assuming that everything needed is already
> downloaded and started.
>
>
>
> On Tue, Mar 25, 2014 at 11:31 AM, Sanne Grinovero <sanne at hibernate.org
> >wrote:
>
> > My vote goes to #1 as well for the short term.
> >
> > There also is a third option, which requires some more work but
> > provides a very nice balance.
> > A great deal of the slowness of this complex matrix execution can be
> > addressed to the continuous startup and teardown of services like the
> > various databases and the datastores.
> >
> > Considering that each of those services starts in less than a second,
> > the problem is not the single startup but literally the compound
> > effect of the complex matrix: if we started say MongoDB, and CouchDb,
> > and all others, and all containers at the beginning of the suite, we
> > could then run matrix tests in a very efficient way, I'd bet we could
> > keep the full matrix *and* the testsuite under a single minute. The
> > goal would be to reuse a single WildFly (or EAP) startup to test on
> > each database; i.e. we need to share the running containers across
> > modules, or merge the integration tests in a single module per
> > container.
> > Not sure how far Maven will be a problem for this.
> >
> > For the OGM needs to test on EAP, I just dicussed with Davide (same
> > office today), and since we'd be testing an old version of EAP
> > (6.1.0.Alpha1 being the latest in public Maven repositories), our idea
> > is that this is too old to be useful anyway. We'll set up a profile -
> > disabled by default - which downloads and tests latest EAP to be used
> > by the Jenkins instance running at Red Hat.
> >
> > Sanne
> >
> >
> > On 25 March 2014 09:25, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > > This is a follow up on
> > >
> >
> https://github.com/hibernate/hibernate-ogm/pull/307#issuecomment-38453092
> > >
> > > We keep piling up new backends, new containers to test and new rules
> > > checked at build time. A consequence is that it is becoming less and
> > > less pleasant to work on OGM.
> > >
> > > You can see that n version of Naked+WF+EAP+... multiplied by m backends
> > > simply will make this project horrendously slow to contribute to.
> > > I imagine n = 3 or 4 and m = 10 in a medium term.
> > >
> > > I see two options that would keep us around for a while:
> > >
> > > 1. Make the container integration tests only run with a specific option
> > >    activated on the CI.
> > > 2. Move the container integration tests outside in a different repo
> > >    altogether.
> > >
> > > I do prefer 1.
> > >
> > > Emmanuel
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>