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-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 <[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. > > > > > > > > >
