Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> Please make a ticket in JIRA as a reminder for that and assign it a fix
version of 3.4.0 so we don't forget.
Done:
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
Here's what I just did:
* Confirmed that SNAPSHOT does not deploy images.
* Confirmed that 3.2.10-rc1 deploys 3.2.10-rc1 only - don't see 3.2 up
there any more
I guess
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
Just pushed two CTR commits to hopefully get the tags right:
[aac534e11](https://github.com/apache/tinkerpop/commit/aac534e11fa406bedc61dbc060d06740b898e170)
adds a check to only
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
Updated the DockerHub descriptions a bit - looks prettier now:
https://hub.docker.com/r/tinkerpop/gremlin-server/
https://hub.docker.com/r/tinkerpop/gremlin-console/
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
so - that changes works. we can tweak it now if necessary now that we know
it works:
https://github.com/apache/tinkerpop/commit/144c69801de8135ac04663da4063260378c71336
> But
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> I believe that aspect of this works fine. Nothing deploys when the
version is a SNAPSHOT.
But do we want to add the `3.2` tag for a `3.2.10-rc1` image? That means
that users
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> Yes and the 3.2 tag should only exist for non-SNAPSHOT versions,
I believe that aspect of this works fine. Nothing deploys when the version
is a SNAPSHOT.
> But maybe we
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> Separately, do I need to edit the repository short/long description
manually? can that not be automatically done on deploy using content from our
github repo?
I'm afraid that
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> I only see the 3.2 tag - where the 3.2.10-rc1? shouldn't that be up there
too?
Yes and the `3.2` tag should only exist for non-SNAPSHOT versions, but I
guess that we didn't
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
I've published but look at what is up there:
https://hub.docker.com/u/tinkerpop/
I only see the 3.2 tag - where the 3.2.10-rc1? shouldn't that be up there
too?
---
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> I also just pushed a minor update to make the command more like our
others with -DdockerImages rather than explicitly using the -P directly which
we typically dont' do. Also disabled
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
@FlorianHockmann I think you can merge this. I will do the deploy
afterwards when I can tag the rc1 properly. If something goes wrong we can just
CTR in some fixes. I'm feeling pretty
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
ah - yea, i did, but forgot. i think others should be free to vote now
though. let's just hold the merge until i get a minute to test that. i think i
can get to that this week, though i guess
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
@spmallette you now voted +1 on this but didn't you want to push release
candidates of the Docker images during the review?
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
I made a minor comment on the last dev doc update to the pre-flight check.
Other than that:
VOTE +1
---
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
No, you're right. That is something that is very unlikely to occur and I
can't think of other (more likely) reasons where the build of the docker images
could fail as they really only
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> detect when changes break the Docker images, e.g., when the naming of the
zip archives or their location changes
That's fair, though that specific example seems really unlikely to
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> what is the advantage to building these images if a .docker file is
present?
A reason to keep this option is that it makes it easier to detect when
changes break the Docker
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
Rebased and removed the hard-coded version. The major and minor version are
now parsed with the `build-helper-maven-plugin` and added as tags to the image
when it's not a `SNAPSHOT`
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
@FlorianHockmann could you rebase this please? maybe we can try to get this
polished up now.
---
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> move that entire configuration to the root pom.xml
Good point @spmallette, I just pushed a commit for that and also rebased
the PR.
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
Since the `build-helper-maven-plugin` configuration is identical in both
the gremlin-server/gremlin-console pom.xml files and the "SNAPSHOT detection"
would be generally useful (i think it has
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
I'm ok with merging this after the next release. Starting with a release
candidate first like we usually do for GLVs makes sense in my opinion. Then we
can also deal with things like the
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
I haven't looked at this in detail yet, but is your intent to see this
merged before we release 3.2.8/3.3.2? Personally, I'd like to see it wait until
a following release so that we don't need
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
Thanks @spmallette, that actually looks like a good solution.
I just pushed a commit that uses this solution. This not only allows
skipping of `docker push` for SNAPSHOT versions,
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
i saw a few solutions to the issue of skipping when SNAPSHOT - not sure
which is best, but here's one:
https://stackoverflow.com/a/39139979/1831717
we might actually find
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
I just verified my assumption that `docker login` should be enough to get
deployment of Docker images working through Maven and added a short description
of that to the dev docs.
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
> Otherwise I could also test deployment with this plugin with some test
image to a private repo and then write the dev docs.
That would be great if you could test things out in
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
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
I just reset my docker account password and it turns out that i'm one of
the owners on the TinkerPop organization - so that's good.
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/802
Thanks for doing this @FlorianHockmann - i'm just dumping my brain of
questions and thoughts on this one.
So `mvn deploy` will deploy to where? dockerhub? If so, could you include
31 matches
Mail list logo
