> On Jun 30, 2020, at 2:10 PM, Anthony Baker <bak...@vmware.com> wrote: > > When evaluating technical alternatives I think it’s helpful to look at data. > Has anyone recently tried to run the entire dunit test suite in parallel w/o > docker? How many tests need to be changed? IIRC, there would be non-trivial > work in product code around statics and system properties as well.
The issues of globals, singletons and system properties is still an issue in the Docker plugin world and its why we recycle the process in the container after each test, `forkEvery = 1`. We would do the same for plain forked runner. > Maybe pursuing a dual short-term / long-term approach ends up being the most > realistic approach. Oh I think that is a must. We won’t be able to address all tests with a short term fix to eliminate docker plugin, nor do we want to stick with docker plugin and never upgrade Gradle or JUnit. I suggest we hit on module and test category at a time and burn down the debt that way. First step would be to find a way to keep the docker configuration from being applied to specific cleaned up test tasks. Then apply that change to one task in one module and test. > @Jake have you tried using the testcontainer project with dunit? Maybe it’s > possible to use GenericContainer with an open RMI port. I am not sure how you think that will work. The problem testcontainers solves well is the single port service where the client doesn’t care what the port is. So things like databases, web servers, etc are really easy. Geode is hard because we have multiple ports for multiple services. The services have to talk to each other, so you will need to compose some networking between the containers. The client and the server have to agree on ports given the locator resolution, or we invent service gateway here too. Are you perhaps thinking about the DUnit VMs concept and running those in one or more containers? That might work, there is some trickiness in getting getting the current built bits into the containers. Again, the testcontainers model is around some static image for a resource, like a database. We would be building a container around the currently built binary and tests or mounting them into the container at least, like the Gradle docker plugin does. This would only address clean DUnit tests and not other integration tests that spin up embedded servers, launch gfsh, etc. -Jake
