The server starts but something seems messed up with the ports. It's like I can't connect to the 45940 port from the host. I tried a couple things I saw on stackoverflow but nothing i tried seemed to fix it. it's probably something simple...any ideas?
On Fri, Mar 1, 2019 at 10:05 AM Robert Dale <[email protected]> wrote: > I made a first attempt. Let me know what you think. > https://github.com/apache/tinkerpop/pull/1075 > > Robert Dale > > > On Wed, Feb 27, 2019 at 11:32 AM Stephen Mallette <[email protected]> > wrote: > > > > If we agree on Testcontainers in general, then I can give this a try > and > > use Testcontainers in one of our Java projects that need Gremlin Server > for > > testing (gremlin-driver maybe?). > > > > The java integration tests for Gremlin Server flip a lot of configuration > > bits per test. I don't know how that works with testcontainers and if it > > will make our testing there any better. There are also a number of tests > > that stop/start the server under different conditions - not sure how that > > works with testcontainers either. Finally, wouldn't we expect adding > docker > > to the mix to slow down our integration test runs for java? > > > > I don't want to seem like i'm completely against testcontainers btw. I > just > > wonder if a script doesn't give us a 100% better experience than what we > > have now (which is nothing). If so, and the script is easy and > zero-impact > > without new dependencies, then I think I like that approach. Also, It > would > > be nice to have the script for other sorts of manual testing, such as > > testing Gremlin Console with Gremlin Server. If we'd like to do > > testcontainers for GLVs I suppose that can be done too, but for my > > purposes, since I was the one who asked for help with this initially, > > testcontainers doesn't sound like something that is an absolute > requirement > > for my needs. > > > > thanks robert/florian for all the discussion and help - appreciated. > > > > On Wed, Feb 27, 2019 at 10:01 AM Florian Hockmann < > [email protected]> > > wrote: > > > > > Yes, except for the detail that Testcontainers could make the script > > > obsolete if it is also used to build the image by itself. That would > have > > > the advantage that developers wouldn't have to execute the script to > > build > > > the image. (Executing the script with Testcontainers could also be a > > > possibility, but I'm not sure how good that works.) > > > > > > If we agree on Testcontainers in general, then I can give this a try > and > > > use Testcontainers in one of our Java projects that need Gremlin Server > > for > > > testing (gremlin-driver maybe?). > > > With such a PR it would probably also be easier for others to see what > > > advantages / disadvantages using Testcontainers would have. > > > > > > I think using a Java project first makes most sense as we can use all > > > functionality Testcontainers has to offer there. The downside is of > > course > > > that we might not have all the functionality afterwards for other > > languages > > > and then we might need to extend the Testcontainers libraries for the > > > different languages. (My assumption here is that we won't need that > much > > > functionality so it should be limited to 1 or 2 missing features.) > > > Alternatively, we could also start with a GLV where the Testcontainers > > > library doesn't have the same functionality which probably means that > we > > > need a workaround to get an image of our current Gremlin Server version > > for > > > testing. > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Robert Dale <[email protected]> > > > Gesendet: Mittwoch, 27. Februar 2019 15:49 > > > An: [email protected] > > > Betreff: Re: docker and GLV development > > > > > > I think there are two components here. > > > 1) Script to build the dockerized test server. Includes ability to > start > > > container manually, externally from tests. > > > 2) Testcontainers integration which uses the docker image from #1. > > > Testcontainers could also include executing the script in #1 to build > the > > > container. > > > > > > Does this sound right to you? > > > > > > Robert Dale > > > > > > > > > On Wed, Feb 27, 2019 at 8:48 AM Florian Hockmann < > [email protected] > > > > > > wrote: > > > > > > > > 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/e81280836feed5df8d6adc8f3a03d > > > > 09988282ea5/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 <[email protected]> > > > > Gesendet: Mittwoch, 27. Februar 2019 13:52 > > > > An: [email protected] > > > > 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 > > > > <[email protected]> > > > > 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 <[email protected]> > > 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 > > > > > > <[email protected]> > > > > > > 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 < > > > > > [email protected] > > > > > > > > > > > > > > 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-pythontestcontainer > > > > > s- > > > > > dotnet > > > > > > > >: > > > > > > > > https://github.com/testcontainers/testcontainers-dotnet > > > > > > > > testcontainers-node > > > > > > > > < > > > > > > > > > > > > > > > > > > > https://github.com/testcontainers/testcontainers-dotnettestcontainer > > > > > s- > > > > > 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 <[email protected]> > > > > > > > > Gesendet: Dienstag, 26. Februar 2019 22:24 > > > > > > > > An: [email protected] > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
