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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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.