Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
I just pushed two commits, one removes the log output as you suggested and
the other one was unfortunately necessary on my system to get all tests running
with `./docker/build.sh -t -n -i`. It simply increases the timeout for one test
in `gremlin-driver` as that was failing consistently for me.
As already discussed on the mailing list, I can't build the documentation
right now, so I can't test if my changes broke anything there.
> So mvn deploy will deploy to where? dockerhub?
My understanding of the `dockerfile-maven-plugin` is that it will simply
wrap `docker push` for deployment which should default to dockerhub.
> If so, could you include something in the dev docs on how you configure
your system to allow for that?
It should be enough to do [`docker
login`](https://docs.docker.com/engine/reference/commandline/login/) once on
your system which should ask for the credentials and then store them in the
config. After that, deployment through maven should just work.
How about we deploy release candidate images once this is merged and then
write the release docs when we've actually done one successful deployment?
Otherwise I could also test deployment with this plugin with some test
image to a private repo and then write the dev docs.
> Also, what happens when we do a mvn deploy on a SNAPSHOT? that would be
bad right? I think we need to prevent such things from happening somehow.
I'm not sure yet about that one yet. It would just result in an image with
a tag like `3.2.8-SNAPSHOT` which shouldn't be a problem.
The ideal case would probably be that we use unique tags like
`3.2.8-SNAPSHOT-abcde` and then tag the latest of these SNAPSHOT images
additionally with `3.2.8-SNAPSHOT`, but just having the `3.2.8-SNAPSHOT` tag
should also be ok.
Now, doing a `mvn deploy` and therefore `docker push` for an image that was
already pushed shouldn't do anything when the artifacts didn't change that go
in that image.
Alternatively, we could also try to disable the deployment phase for this
plugin for `SNAPSHOT` versions, but I don't know how we could do that with
Maven.
> what does adding this extra step do to the the overall build time (when
building docker is enabled, of course)?
I just checked with my Ubuntu VM that has just 4 cores and 6 GB RAM and got
the following times for `mvn install -pl gremlin-server -DskipTests`:
* Without docker build enabled: 33s
* With docker build enabled and no images present: 2:10 min
* With docker build enabled, but the image already present: 51s
When no images are present locally, then it has to download and extract the
OpenJDK image which is 82 MB big, that took a big part of that time.
---
