[aerogear-dev] New proposal: Making integration test specific repo

[Karel Piwko]

My only concern about having test integration tests repos separated is a boom
of repositories in Aerogear organization. If this does not happen to be a
problem, I'm fine with that.

On Tue, 30 Jul 2013 07:40:09 -0500
Kris Borchers <kris at redhat.com> wrote:

> Bruno and I have already started working on something like this for JS. I
> have a couple of comments inline which will illustrate why I think this
> should be separated by component and not one single aerogear-test-harness
> repo.
> 
> On Jul 30, 2013, at 3:31 AM, Karel Piwko <kpiwko at redhat.com> wrote:
> 
> > Hi all,
> > 
> > there were already plenty of discussions about integration tests in Aerogear
> > [1-6]. As these are something most people want to execute in CI only and QE
> > wants to have better control over commits, I'd like to introduce new model
> > that I hope will improve current state:
> > 
> > * Integration tests are hosted in separate repository, e.g.
> >  aerogear/aerogear-test-harness
> 
> +1 but would prefer that each component (JS, Android, iOS, etc.) have their
> own integration test repos
> > * Aerogear components do not contain integration tests
> 
> +1
> > * Aerogear components have .travis.yml modified to clone
> > aerogear-test-harness repository and execute appropriate component
> > integration tests in CI after each commit into component
> 
> This is the part where I think they need to be separate. I don't want to have
> to clone that entire repo including the tests and config for other components
> when I am testing JS.
> > * QE and devs have commit access to aerogear-test-harness repository
> 
> +1 to QE having access to all testing repos
> > * Aerogear-test-harness contains modules per integration test scenario, e.g.
> >  a module for unified-push-server or a module for simple-push-server. Any
> >  module can use different tools and/or language, whatever fits the test
> >  scenario best way.
> 
> Again, this is solved by separate repos.
> > 
> > Tolis already solved outstanding technical problems, either it is
> > requirement to depend on latest component state without polluting
> > repository with local installation, versioning or ability to make it
> > importable to an IDE.
> > 
> > Let me know if you like it, we can proceed filling its content today.
> > 
> > Thanks,
> > 
> > Karel
> > 
> > [1] http://lists.jboss.org/pipermail/aerogear-dev/2013-May/002471.html
> > [2] http://lists.jboss.org/pipermail/aerogear-dev/2013-July/003912.html
> > [3] http://lists.jboss.org/pipermail/aerogear-dev/2013-July/003944.html
> > [4] http://lists.jboss.org/pipermail/aerogear-dev/2013-July/003979.html
> > [5] http://lists.jboss.org/pipermail/aerogear-dev/2013-July/004127.html
> > [6] http://lists.jboss.org/pipermail/aerogear-dev/2013-July/004096.html
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev