> I do like the idea of being able to test against older versions though.
That shouldn't be a problem in general as we could use multiple different images. See for example this PR that adds Testcontainers to JanusGraph to test different Elasticsearch versions: https://github.com/JanusGraph/janusgraph/pull/1409 > Yes, an on-the-fly container would work We could however also use an on-the-fly container with Testcontainers. We would just need some automation to build the image in the background. What if we would build an image during the usual Maven build for testing and give it a descriptive tag like "testing". Then, we could use that tag with Testcontainers in addition to tags for already released versions. Testcontainers-Java can apparently even build images by itself. So, that could also be a possibility to get an image with the latest Gremlin Server with the current (unreleased) changes. In general, I would really like to get away from a situation where we have to start some script in the background before tests can be executed. @Robert: > What is the test configuration/data for GLVs? Could you list the paths/files? For Gremlin.Net for example, you can find the automation happening in the pom.xml of the testing part: https://github.com/apache/tinkerpop/blob/e81280836feed5df8d6adc8f3a03d09988282ea5/gremlin-dotnet/test/pom.xml#L179 It calls the test-server-start.groovy script before the tests are executed and afterwards test-server-stop.groovy script to stop the server again. This has the obvious downside that the tests can only be executed from the Maven build which isn't the build tool .NET developers would use and also not the tool the IDE will use (the situation is basically the same for other GLVs). -----Ursprüngliche Nachricht----- Von: Robert Dale <robd...@gmail.com> Gesendet: Mittwoch, 27. Februar 2019 13:52 An: dev@tinkerpop.apache.org Betreff: Re: docker and GLV development I'm surprised Daniel doesn't have this done already ;-) What is the test configuration/data for GLVs? Could you list the paths/files? Robert Dale On Wed, Feb 27, 2019 at 7:49 AM Stephen Mallette <spmalle...@gmail.com> wrote: > Yes, an on-the-fly container would work assuming it used the test > configuration/data for GLVs. That's why i suggested the command as I > did because it was similar to docker/build.sh. > > > On Wed, Feb 27, 2019 at 7:25 AM Robert Dale <robd...@gmail.com> wrote: > > > Do you want to create a docker container on-the-fly using the > > current working copy kind of like we do for docker/build.sh? > > > > Robert Dale > > > > > > On Wed, Feb 27, 2019 at 7:16 AM Stephen Mallette > > <spmalle...@gmail.com> > > wrote: > > > > > testcontainers seems neat as it gives some good integration and > > automation, > > > however reliance on nightly snapshots doesn't sound so great. > > > There are times when changes are occurring on both client and > > > server so a local up-to-the-moment image would be necessary. I > > > also think we might want > to > > > avoid nightly snapshots of anything until the ASF figures out more > > clearly > > > how those play into projects (there is a bit of discussion going > > > on > with > > > that now). I do like the idea of being able to test against older > > versions > > > though. Ensuring backward compatibility.is a nice thought. > > > > > > > > > On Wed, Feb 27, 2019 at 4:38 AM Florian Hockmann < > f...@florian-hockmann.de > > > > > > wrote: > > > > > > > Fantastic idea, I often missed the ability to just start tests > > > > for Gremlin.Net from my IDE. > > > > > > > > Luckily for us, there is a project that is aimed exactly at > > > > problems > > like > > > > this: > > > > https://www.testcontainers.org/ > > > > > > > > The basic idea of Testcontainers is that you define a Docker > container > > in > > > > your tests for whatever external dependencies you need. > > > > Databases > are a > > > > frequent example where Testcontainers makes sense. For us, > > > > Gremlin > > Server > > > > would be such a container. > > > > Testcontainers then uses the ability of the testing framework (e.g. > > > JUnit) > > > > to start the Docker container for the tests and waits until they > > > > are > > > fully > > > > started (how they are started can be configured for each > > > > container differently). After the tests have completed, it also > > > > stops the > > > containers > > > > again. > > > > That way, you don't have to manage the containers manually anymore. > > > > Everything is done in the background by the IDE / the build tool. > > > > > > > > Testcontainers was originally a Java library, but they now also > > > > have libraries for different languages, including the ones for > > > > which we > have > > > > GLVs: > > > > > > > > testcontainers-python: > > > > https://github.com/testcontainers/testcontainers-python > > > > testcontainers-dotnet > > > > < > > > > > > https://github.com/testcontainers/testcontainers-pythontestcontainers- > dotnet > > > >: > > > > https://github.com/testcontainers/testcontainers-dotnet > > > > testcontainers-node > > > > < > > > > > > https://github.com/testcontainers/testcontainers-dotnettestcontainers- > node > > > >: > > > > https://github.com/testcontainers/testcontainers-node > > > > > > > > Testcontainers-java is the most advanced library of these of course. > > The > > > > others still lack some functionality, but I guess that we could > > > > also > > just > > > > contribute to those libraries if an important feature is missing > > > > for > > us. > > > > > > > > I wanted to use Testcontainers for Gremlin.Net, but > > testcontainers-dotnet > > > > unfortunately can only use images that are available in some > registry. > > > So, > > > > we would have to push a Docker Image of Gremlin Server to > > > > DockerHub > to > > > use > > > > it in our tests. That means that we could either only test the > > > > GLVs > > > against > > > > already released versions or we could publish something like > > > > nightly > > > build > > > > images of Gremlin Server. > > > > I originally wanted to wait until testcontainers-dotnet is able > > > > to > use > > > > images that are only available locally (testcontainers-java > > > > already > has > > > > that capability), but now that I think more about this, I think > > > > that > it > > > > makes actually more sense to use images that are available in > > > > the > > > registry > > > > as every developer would otherwise have to build test images > > > > first > > > locally > > > > in order to use them for tests. > > > > > > > > So, I suggest that you guys take a look at Testcontainers to see > > whether > > > > you agree that it's a good solution to our problem and then we > > > > can > see > > > > whether we want to publish nightly builds for the GLV tests or > > > > how we > > > want > > > > to handle that. > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Stephen Mallette <spmalle...@gmail.com> > > > > Gesendet: Dienstag, 26. Februar 2019 22:24 > > > > An: dev@tinkerpop.apache.org > > > > Betreff: docker and GLV development > > > > > > > > Anyone have any idea how to make it so that docker can be useful > > > > for helping to streamline GLV development? I'd love to be able > > > > to do > > > something > > > > like: > > > > > > > > docker/gremlin-server.sh -test > > > > > > > > which would start Gremlin Server with our standard test > > > > configuration (currently built into the maven tool chain, but I > > > > think that could be extracted without too much difficulty). That > > > > way, we could easily > open > > up > > > > whatever GLV specific IDE we wanted and run tests directly in > > > > there, > > use > > > > the debugger, etc. > > > > > > > > Sound useful? and if so, is that something that is > > > > easy/possible? and > > > then > > > > further....any volunteers with the know-how to get that setup > > > > (i'm > > happy > > > to > > > > assist however i can)? > > > > > > > > btw, if you have a nicer way to set up an environment for GLV > > development > > > > and docker is a waste of time, please clue me in. i don't mind > > > > using > > the > > > > maven integration but i feel like i could be more efficient with > > > > a > more > > > > streamlined setup. > > > > > > > > > > > > > >
