+1. AcceptanceTest seems fittings, although... That test category was created with the focus on tests that run gfsh scripts via the GfshRule. Because the GfshRule uses the built jar and actually launches gfsh to run its tests, all current AcceptanceTests exist in geode-assembly. Perhaps as an oversight, only :geode-assembly:acceptanceTest is a target of the precheckin task.
If we want to expand the scope of the AcceptanceTest tag, we'll need to go update the gradle to make sure these tests get picked up. On Wed, Apr 4, 2018 at 9:39 AM, Kirk Lund <kl...@apache.org> wrote: > +1 to using AcceptanceTest category for the end-to-end JDBC connector > service tests > > On Wed, Apr 4, 2018 at 8:41 AM, Nick Reich <nre...@pivotal.io> wrote: > > > Using AcceptanceTest category seems like a good solution at the moment to > > me. > > > > On Tue, Apr 3, 2018 at 4:29 PM, Sean Goller <sgol...@pivotal.io> wrote: > > > > > I'm actually fine with putting it in AcceptanceTest for now. > > > > > > Ideally I'd like to see something like JDBC connection strings that > could > > > be passed in as properties via the command-line, and if they're not > > present > > > the relevant tests don't get run. That way the entity running the tests > > can > > > decide the best way to enable those tests. > > > > > > On Tue, Apr 3, 2018 at 4:11 PM, Jens Deppe <jde...@pivotal.io> wrote: > > > > > > > I'm in favor of using docker for test isolation. We already have an > > > > 'AcceptanceTest' category which you might consider using instead of > > > > creating yet another category. > > > > > > > > --Jens > > > > > > > > On Tue, Apr 3, 2018 at 2:02 PM, Nick Reich <nre...@pivotal.io> > wrote: > > > > > > > > > Team, > > > > > > > > > > As part of validating the new JDBC connector for Geode, we have a > > need > > > > for > > > > > tests that involving connecting to specific databases (like MySQL > and > > > > > Postgres) to validate proper function with those databases. Since > > these > > > > > tests require connecting to outside services, unlike existing Geode > > > > tests, > > > > > we are seeking suggestions on how to best incorporate such tests > into > > > > > Geode. The approach we have taken so far is to utilize Docker (and > > > Docker > > > > > Compose) to take care of spinning up our external services for the > > > > duration > > > > > of the tests. This, however requires that Docker and Docker Compose > > be > > > > > installed on any machine that the tests are run on. Additionally, > the > > > > > Concourse pipeline for validating develop is incompatible with use > of > > > > > Docker for distributed tests, due to the way they are already being > > run > > > > > within Docker containers of their own (it seems possible to make it > > > work, > > > > > but would add overhead to all tests and would be a challenge to > > > > implement). > > > > > > > > > > To address these issues, we are considering having these tests run > > > under > > > > a > > > > > new task, such as "serviceTest" (instead of IntegrationTest or > > > > > distributedTest). That way, developers could run all other tests > > > normally > > > > > on their machines, only requiring Docker and Docker Compose if they > > > wish > > > > to > > > > > run these specific tests. This would also allow them to be their > own > > > task > > > > > in Concourse, eliminating the issues that plague integrating these > > > tests > > > > > there. > > > > > > > > > > Are there other ideas on how to manage these tests or concerns with > > the > > > > > proposed approach? > > > > > > > > > > > > > > >
